Re: Wildcard DNS. Re: rfc 3280bis

[Philipp Gühring <[e-mail]>]

Hi,

> >  As Philipp says, a standard would need to specify how subdomain
> > matching is performed: does "*.bar.com" match "bar.com" or not?
>
> Similarly, does "*.wisc.edu" match "info.doit.wisc.edu"? 

Ok, perhaps some feedback from the certificate issueing practice helps:

Most of the certificates I saw from our users are the following way:

CN=wisc.edu
SAN=*.wisc.edu
SAN=wisc.edu

Since some browsers do not match *.wisc.edu as wisc.edu, the conservative 
method for issueing a certificate to ensure that it works is to include both 
*.wisc.edu and wisc.edu.
(And to ensure that it also works with applications that haven´t heard about 
SAN yet, and still use the CommonName, they usually include one hostname in 
the CommonName that is also contained in the SAN)

From the regular expression methodology, the correct way would be that 
*.wisc.edu does not match wisc.edu

Con: The main application for multiple hostnames in my opinion is  
www.domain.com and domain.com, having a webserver respond to both 
http://www.domain.com/ and http://domain.com/ so that it also works in all 
browsers when people forget to write the www. in front.

smaller certificates. that only contain *.wisc.edu, but bytes are cheap 
nowadays, so who cares if the certificates are a kilobyte larger or not. (I 
haven´t had any customers who complained that their certificates are too 
large yet)

I don´t remember having seen someone with *.*.wisc.edu certificates yet.
Either they calculate with enough browsers supporting *.wisc.edu to match 
info.doit.wisc.edu, or they don´t need it to match that. (I guess that it´s 
not needed that often)

From the security perspective, I think it would be bad if *.bar.com would 
match www.bankofamerica.com.bar.com unexpectedly.

So from my perspective, I think we don´t need *.wisc.edu to match wisc.edu or 
www.sub.wisc.edu, and we could live with a standard that says that it must 
not match anything else. Has anyone seen any applications where matching 
www.sub.wisc.edu or wisc.edu would be needed?

> At one
> time in the past, any maybe still, whether it did or not depended on
> which browser was being used.

Yes, that´s still the case.

Best regards,
Philipp Gühring





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KNR4uj064346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 16:27:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KNR4Kh064345; Wed, 20 Feb 2008 16:27:04 -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.13.5/8.13.5) with SMTP id m1KNR2f6064338 for <[e-mail]>; Wed, 20 Feb 2008 16:27:03 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19400 invoked from network); 20 Feb 2008 23:19:29 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;20 Feb 2008 23:19:29 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 23:19:29 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Wed, 20 Feb 2008 18:27:01 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0DcREqk1ogZGJQeeIOs6Zuahj9gACVKkw
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "Turner, Sean P." <[e-mail]>
Cc: "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1KNR3f6064340
Sender: [e-mail]
Precedence: 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,

The answer to your question regarding "Clearance" is that it is a
separate extension.  Do you think that the I-D needs to be clarified.

In terms of using SDA instead, I am ok with it being in SDA or a
separate extension.

In terms of security categories, we have exposure to some "security
policies" where some categories are restrictive and hence intersection
is appropriate and some are permissive and hence union is appropriate.
That is why we did not write the rules.

In terms of CA clearance constraint, some implementations need to limit
the TA and that is why the constraint appears in the TA.  As to the end
entity, we explicitly state that CA clearance constraint will not appear
in end entity.  In terms of a Signing CA, the flexibility of CA
clearance constraint in lowest layer CA is useful depending on which
parent issues it a certificate since these constraints are imposed
during path validation.  Depending on what path is chosen clearances
asserted in an end entity certificate may be valid or not. 

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of David A. Cooper
Sent: Wednesday, February 20, 2008 4:46 PM
To: Turner, Sean P.
Cc: pkix
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID




Turner, Sean P. wrote:
>
> We followed in Stefan's footsteps [RFC 4262] where an attribute
> (SMIMECapabilities) got turned in to an extension. The precedent has
been
> set we just followed it. I don't think we need to look at RFC 3281 to
say
> where the information can or can't go. X.501 and other places where
sytnax
> is defined doesn't say where all the info can go.
>   

When I scanned this document some time ago, I was unsure how one was 
expected to include clearance information in a certificate.  Section 2 
of the draft begins:

   The Clearance certificate extension in a certificate indicates the
   clearances held by the subject.  It uses the clearance attribute
   syntax from Section 4.4.6 of [RFC3281] in the Subject Directory
   Attributes extension.  The Clearance certificate extension MUST never
   be marked critical.

The statement about criticality implied that this was an extension, but 
the second sentence suggested that it should appear in the 
subjectDirectoryAttributes extension.

I do not understand why this draft specifies that this attribute should 
be encoded as an extension.  The clearance attribute is defined as an 
Attribute.  The subjectDirectoryAttributes extension was defined for the

specific purpose of allowing attributes to be included in certificates.

X.501, which defines the clearance attribute, states that if a clearance

attribute is to be included in a public key certificate, it should be 
placed in the subjectDirectoryAttributes extension.

Why do people feel that there is a compelling reason to avoid using the 
subjectDirectoryAttributes extension when encoding an attribute in an 
extension?

>> 4 - With the proposed definition of the constraints, no 
>> standard code would be available, since the details of the 
>> securityCategory field would be left undefined. One main goal 
>> of RFCs is to allow for interoperability testing.
>>     
>
> So there are other standards that have essentially ANYs in them where
> interoperability was achieved I believe we can do the same thing here.
There
> is an ISO standard (ISO 15816) that defines categories, but honestly
I'd
> like to decouple that discussion from this discussion. 
>   

The processing rules for the CAClearanceConstraints extension includes 
the following rule:

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

Why do you believe that it is reasonable to publish this draft with such

an incomplete processing rule included?  How do you expect people to 
implement this CAClearanceConstraints extension?

Is there an assumption that inclusion of securityCategories in 
CAClearanceConstraints extensions will be rare and so it is acceptable 
for a generic implementation to simply reject certification paths that 
include a CAClearanceConstraints extension with securityCategories?  
Alternatively, do you expect that there will be a limited number of 
security policies and there is a plan to publish a second document that 
lists these security policies along with the rules for performing the 
above calculation for each of the security policies?

You say that other standards do something similar.  Can you point to 
specific examples where a standard has been approved despite leaving 
things as open ended as this?

Dave

P.S. I also do not understand the reason for including the 
CAClearanceConstraints extensions in a trust anchor certificate.  If a 
CA wants to effectively impose such constraints, shouldn't it include 
the constraint information in all (non-self-issued) CA certificates that

it issues.  As for end entity certificates, the CA can constrain itself 
by simply not issuing any certificates that violate the constraint.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KNHfHK063699 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 16:17:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KNHfFe063698; Wed, 20 Feb 2008 16:17:41 -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.13.5/8.13.5) with SMTP id m1KNHepY063691 for <[e-mail]>; Wed, 20 Feb 2008 16:17:41 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 19333 invoked from network); 20 Feb 2008 23:10:06 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;20 Feb 2008 23:10:06 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 20 Feb 2008 23:10:06 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Date: Wed, 20 Feb 2008 18:17:39 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Thread-Index: AchzvA+hBfjdWRdDSOmAi58C4PVltQAQzOFg
References: <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1KNHfpY063693
Sender: [e-mail]
Precedence: 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 inline... 

<snip>

We both agree that specifying the format is the major goal. 
However the current text does not say it yet.

The concept of TA is defined in RFC 3280 and since 3280bis will be soon
issued, it will not be changed before many years.

[CRW] The current draft requires compatibility with RFC3280.  

It is not possible to use the same name, i.e. TA, with two different
meanings.

So you should use a different name for a "TA with associated data".
For the time being let us call it TAAD.   

[CRW] I don't see the need for this distinction.  There have been two TA
structures posted so far (the definitions in 3125 and TAMP).  Both are
similar and could be viewed as a "TA with associated data".  RFC3280bis
does not include the inputs to path validation in its TA definition, so
that information would be associated data.  

A TA Store is not simply an addition of TAADs. 
Some additional data may apply for all TAADs present in given TAS (TA
Store).
Let us call it for the time being: TASAD.

The content of a TAS may then be modelized as: TASAD + sigma (TAAD)

With this model in mind, I would agree that it is possible to add or
remove a TAAD as a whole.

We will have to identify what kind of data can be associated with a TAS
and what kind of data can be associated with a TA. 

Do you agree with the above concepts
(leaving aside the terminology that can be changed) ? 

[CRW] The idea of TA store data independent of TA data is interesting
and ought to be considered.

<snip>

Would you be able to elaborate, or provide an example for pull ?

[CRW] The language in the 2nd paragraph of section 3 aims to support the
generation of a TA mgmt message that is targeted such that unintended
trust anchor stores reject the message.  Whether the message is pushed
or pulled doesn't matter.  For example, if I generate a TA mgmt message
that targets one TA store to add a TA and try to use that message to add
the TA to a different trust store then the operation should fail.

<snip>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KLlklm057518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 14:47:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KLlkFk057517; Wed, 20 Feb 2008 14:47:46 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KLli6C057510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 20 Feb 2008 14:47:45 -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 m1KLlcMe018429; Wed, 20 Feb 2008 16:47:39 -0500
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 m1KLlVZH001195; Wed, 20 Feb 2008 16:47:31 -0500
Message-ID: <[e-mail]>
Date: Wed, 20 Feb 2008 16:46:10 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: "Turner, Sean P." <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie>
In-Reply-To: <026501c873e6$c819de70$0301a8c0@Wylie>
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>

Turner, Sean P. wrote:
>
> We followed in Stefan's footsteps [RFC 4262] where an attribute
> (SMIMECapabilities) got turned in to an extension. The precedent has been
> set we just followed it. I don't think we need to look at RFC 3281 to say
> where the information can or can't go. X.501 and other places where sytnax
> is defined doesn't say where all the info can go.
>   

When I scanned this document some time ago, I was unsure how one was 
expected to include clearance information in a certificate.  Section 2 
of the draft begins:

   The Clearance certificate extension in a certificate indicates the
   clearances held by the subject.  It uses the clearance attribute
   syntax from Section 4.4.6 of [RFC3281] in the Subject Directory
   Attributes extension.  The Clearance certificate extension MUST never
   be marked critical.

The statement about criticality implied that this was an extension, but 
the second sentence suggested that it should appear in the 
subjectDirectoryAttributes extension.

I do not understand why this draft specifies that this attribute should 
be encoded as an extension.  The clearance attribute is defined as an 
Attribute.  The subjectDirectoryAttributes extension was defined for the 
specific purpose of allowing attributes to be included in certificates.  
X.501, which defines the clearance attribute, states that if a clearance 
attribute is to be included in a public key certificate, it should be 
placed in the subjectDirectoryAttributes extension.

Why do people feel that there is a compelling reason to avoid using the 
subjectDirectoryAttributes extension when encoding an attribute in an 
extension?

>> 4 - With the proposed definition of the constraints, no 
>> standard code would be available, since the details of the 
>> securityCategory field would be left undefined. One main goal 
>> of RFCs is to allow for interoperability testing.
>>     
>
> So there are other standards that have essentially ANYs in them where
> interoperability was achieved I believe we can do the same thing here. There
> is an ISO standard (ISO 15816) that defines categories, but honestly I'd
> like to decouple that discussion from this discussion. 
>   

The processing rules for the CAClearanceConstraints extension includes 
the following rule:

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

Why do you believe that it is reasonable to publish this draft with such 
an incomplete processing rule included?  How do you expect people to 
implement this CAClearanceConstraints extension?

Is there an assumption that inclusion of securityCategories in 
CAClearanceConstraints extensions will be rare and so it is acceptable 
for a generic implementation to simply reject certification paths that 
include a CAClearanceConstraints extension with securityCategories?  
Alternatively, do you expect that there will be a limited number of 
security policies and there is a plan to publish a second document that 
lists these security policies along with the rules for performing the 
above calculation for each of the security policies?

You say that other standards do something similar.  Can you point to 
specific examples where a standard has been approved despite leaving 
things as open ended as this?

Dave

P.S. I also do not understand the reason for including the 
CAClearanceConstraints extensions in a trust anchor certificate.  If a 
CA wants to effectively impose such constraints, shouldn't it include 
the constraint information in all (non-self-issued) CA certificates that 
it issues.  As for end entity certificates, the CA can constrain itself 
by simply not issuing any certificates that violate the constraint.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KHfD7S029681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 10:41:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KHfD2G029680; Wed, 20 Feb 2008 10:41:13 -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.13.5/8.13.5) with SMTP id m1KHf9U9029652 for <[e-mail]>; Wed, 20 Feb 2008 10:41:11 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 64647 invoked from network); 20 Feb 2008 17:41:03 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.231.128.115 with login) by smtp100.biz.mail.re2.yahoo.com with SMTP; 20 Feb 2008 17:41:03 -0000
X-YMail-OSG: tRYjE2UVM1nQoyK2vfz5wkxzuQ.k3VTnMkuOXBVQlWVHApkynsppOJQCkT_3Y5W5vjpWcpZ1W8iqckBe2yORLUXp
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Denis Pinkas'" <[e-mail]>, <[e-mail]>
References: <[e-mail]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Wed, 20 Feb 2008 12:34:01 -0500
Organization: IECA, Inc.
Message-ID: <026501c873e6$c819de70$0301a8c0@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.3198
In-Reply-To: <[e-mail]>
Thread-Index: AchYIzGkzHPqmsr2RbKUCMgZwBWhZwAM2o6A
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Denis,

Comments inline.. 

spt

>-----Original Message-----
>From: [e-mail] 
>[mailto:[e-mail]] On Behalf Of Denis Pinkas
>Sent: Wednesday, January 16, 2008 3:52 AM
>To: [e-mail]
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
>Sean,
>
>1 - You say: "we allow multiple securityCategories with one policyId". 
>The problem is that the same classList would apply. This would 
>not allow to grant to the same individual both TOP SECRET 
>COMMERCIAL and CONFIDENTIAL TECHNICAL.

You register a policy company XYZ - it gets an OID. In that policy you say
what classList bits you support. You can add new ones say bits 7 and 8 and
call them TOP SECRET COMMERCIAL and CONFIDENTIAL TECHNICAL. If you're
getting at that the first set of numbers is reserved essentially, I don't
think we should reopen that because we already had that argument in S/MIME
(and maybe also in PKIX).

>2 - I do not see the value of duplicating text from RFC 3281.
>The attribute      id-at-clearance OBJECT IDENTIFIER ::= { 
>joint-iso-ccitt(2) 
>       ds(5) module(1) selected-attribute-types(5) 
>clearance(55) } defined in the ID is the same as the attribute
>       name      { id-at-clearance }
>       OID       { joint-iso-ccitt(2) ds(5) module(1)
>                   selected-attribute-types(5) clearance (55) 
>} defined in RFC 3281.
>
>The differences are as follows:
>  a) RFC 3281 does not say that the extension can be placed in a PKC.
>  b) RFC 3281 does not say how many instances can be placed in an AC.

We followed in Stefan's footsteps [RFC 4262] where an attribute
(SMIMECapabilities) got turned in to an extension. The precedent has been
set we just followed it. I don't think we need to look at RFC 3281 to say
where the information can or can't go. X.501 and other places where sytnax
is defined doesn't say where all the info can go. 

>3 - Supporting such an attribute in ACs, has nothing to do 
>with supporting an AA hiearchy.
>But this is a non issue. RFC 3281 supports this attribute for ACs.

I think relying on RFC 3281 means you need an AA (AC issuer) to issue you an
AC. There's not a lot of those around.

>4 - With the proposed definition of the constraints, no 
>standard code would be available, since the details of the 
>securityCategory field would be left undefined. One main goal 
>of RFCs is to allow for interoperability testing.

So there are other standards that have essentially ANYs in them where
interoperability was achieved I believe we can do the same thing here. There
is an ISO standard (ISO 15816) that defines categories, but honestly I'd
like to decouple that discussion from this discussion. 

>5 - There is no RFC 3281 vs. X.501 battle, since the ASN.1 
>definition is the same.
>The question is whether the RFC 3281 / X.501 definition is 
>adequate in practice.
>IMO, it would work, if two changes are made to the ID :
>
>a)  multiples instances of this attribute should be allowed. 
>On the contrary, it would be possible to grant to the same 
>individual both TOP SECRET COMMERCIAL and CONFIDENTIAL 
>TECHNICAL (see argument 1).

See answer to 1 above.

>b) some standard OIDs for securityCategories should mandated 
>to support in order to allow for interoperability (see argument 4).

See response to #4

spt

>Denis
>
>=======================================================================
>
>>Denis,
>
>>Thanks for taking the time to read the ID.  Responses to your 
>comments 
>>inline.
>
>>spt
>
>>>Sean and Santosh,
>>>
>>>I browsed through the draft.
>>>
>>>While I believe that it might be useful to work on this topic, I do 
>>>not agree with the content of the draft on several aspects.
>>>
>>>First of all, a clearance is much better placed in an attribute 
>>>certificate (AC) rather than a PKC :
>>>Different AAs (Attribute Authorities) may grant different security 
>>>clearances, while a given CA will in practice only grant clearances 
>>>under the same policyID.
>>
>>I really, really, really want to agree, but supporting an AA hiearchy 
>>to issue clearances that are actually in some instances good 
>for longer 
>>than many a certificate's validity periods - makes me think the AA 
>>implementation headache isn't worth it. This is my opinion 
>though - you may disagree.
>>
>>>The document should be applicable as well to extensions 
>placed in ACs.
>>
>>We don't prohibit these extensions from being included in attribute 
>>certificates, but I am also not sure we have to explicitly 
>say they can 
>>be included in attribute certificates.
>>
>>>RFC 3281 which is a copy and paste of X.501 with some adaptations is 
>>>not a practical solution.
>>
>>I'll let the RFC 3281 vs. X.501 battle be waged somewhere else ;)
>>
>>>The draft allows only one clearance certificate extension. 
>>>This does not reflect real world situations where, given one 
>policyId, 
>>>there will be different securityCategories, each one with a 
>different 
>>>sensitivity (which is a much better word than "class").
>>>This restriction should be removed.
>>
>>There's no restriction to remove - we allow multiple 
>securityCategories 
>>with one policyId.
>>
>>>As already mentioned on the list, the classList definition is 
>>>incorrect for the two first bits and does not even support 
>the example 
>>>from section 1: HIGHLY CONFIDENTIAL and GENERAL (called "security 
>>>classification values", which is not an adequate terminology).
>>
>>The bits are reserved, as per RFC 3281, so we can't change them.
>>
>>>In addition, the text says:
>>>
>>>      policyId identifies the security policy to which the clearance 
>>>      relates.  The policyId indicates the semantics of the 
>classList 
>>>      and securityCategory fields.
>>>
>>>If this is the case, rather than an OID and ANY DEFINED by 
>the OID, it 
>>>would be better to use UTF8String.
>>
>>Again we imported the ASN.1 because I think reuse is better 
>than making 
>>something new because we'd like to just match the clearance policyId 
>>OID to the security-policy-identifier OID from the ESS 
>Security Label. 
>>I think not using an OID is a really bad idea.
>>
>>>Another argument is interoperability: the current definition of 
>>>SecurityCategory is too open to allow for interoperability.
>>>The RFC should allow, from the beginning, to implement interoperable 
>>>solutions.
>>
>>Because we can't agree to a common security policy for the Internet - 
>>I'd suggest we not try to explore this rathole. We didn't do it in 
>>S/MIME and I don't think we should do it here.
>>
>>>The text also says:
>>> 
>>>      classlist identifies the security classifications. Six basic 
>>>      values are defined in bit positions 0 through 5 and 
>more may be 
>>>      defined by an organizational security policy. 
>>>
>>>This is untrue. The additional bits cannot be defined by an 
>>>organizational security policy, but only by an addition to the RFC 
>>>(make a parrallel with the keyUsage bits)
>>
>>I disagree completely. You register an OID in a registration 
>document. 
>>In that document you can list your syntax and what the bits mean - if 
>>you expand the syntax you put it there. To get interop, you need to 
>>publish the syntax - you might do it in an RFC or you might not.
>>
>>>This raises the question of compatibility with X.501 section 19.5.
>>>In my opinion, we should not stick to the X.501 definition, if there 
>>>are good reasons not to do so.
>>
>>I agree, but I haven't heard a good reason to change yet.
>>
>>>There is no discussion at all about the criticality of this 
>extension, 
>>>even in the security considerations section.
>>
>>We do discuss criticality. Section 2 and 3, where the extensions are 
>>defined, indicate that the clearance extension is never critial and 
>>that the CA clearance extension may be critical.
>>
>>>The security considerations section contains the following sentence:
>>>
>>>   Certificate issuers must recognize that absence of the 
>>>   CAClearanceConstraints in a CA certificate means that in terms of 
>>>the
>>>   clearance, the subject CA is not constrained. 
>>>
>>>This sentence is incorrect for two reasons:
>>>
>>>1) it seems to apply to Relying parties (RPs), not CAs,
>>>2) this is inconsistent with all the rules which are 
>established about 
>>>the criticality of extensions.
>>>
>>>A RP (or a CA) does not have to recognize the absence of an 
>extension, 
>>>whatever the extension may be.
>>
>>What we're saying is if you don't include the 
>CAClearanceConstraints in 
>>a CAs certificate it is unconstrained. I could tweak the 
>wording to say that.
>>I did not intend to imply the two reasons you cite.
>>
>>>Finally, the CA clearance constraints extension only makes 
>sense in a 
>>>close community of CAs, where all CAs are constrained one way or 
>>>another by a TA. This should be clearly advertised upfront in the 
>>>introduction.
>>
>>I disagree with this. In a cross-certified environment where the 
>>domains understand each others policies this could work.
>>
>>>Denis
>>>
>>>>Santosh Chokhani and I have produced an ID that defines an 
>extension 
>>>>that holds a subject's clearance. The ID also defines an extension 
>>>>called clearance constraints to limit the clearance values a
>>>CA should
>>>>place in subordinate certificates. Finally, it defines the 
>>>>certification path processing rules to determine the
>>>clearances for the
>>>>subject of the certificate based on the clearance and clearance 
>>>>constraints asserted in the certification path. The ID can be
>>>found at:
>>>>
>>>>http://www.ietf.org/internet-drafts/draft-turner-caclearanceco
>>>nstraints
>>>>-00.t
>>>>xt
>>>>
>>>>We're hoping that PKIX would be willing to adopt this as a 
>work item. 
>>>>
>>>>spt
>
>
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KH5IBp025913 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 10:05:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KH5I3u025912; Wed, 20 Feb 2008 10:05: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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KH5GpD025902 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Wed, 20 Feb 2008 10:05:17 -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.240.5; Wed, 20 Feb 2008 17:05:15 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Wed, 20 Feb 2008 17:05:10 +0000
From: Stefan Santesson <[e-mail]>
To: pkix <[e-mail]>
Date: Wed, 20 Feb 2008 17:04:44 +0000
Subject: Call for agenda items, Philadelphia IETF
Thread-Topic: Call for agenda items, Philadelphia IETF
Thread-Index: Achz4rCMDGHAmfpxQ526+JqfDUXcDw==
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_9F11911AED01D24BAA1C2355723C3D320DE289ADA4EAEXMSGC332eu_"
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_9F11911AED01D24BAA1C2355723C3D320DE289ADA4EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Time to set the agenda for the Philadelphia PKIX meeting.

Anyone wanting a slot should send me an e-mail as soon as possible, no late=
r than EOD Wednesday next week (Feb 27).
As usual I want the lead editor for every current pkix draft to tell me if =
they want a slot or not.

We are currently scheduled as a Monday morning session from 0900-1130, whic=
h means two things.
1) We have 2.5 hours available which should be plenty of time.
2) We need to have everything set, including presentations sent to me by Su=
nday night.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


--_000_9F11911AED01D24BAA1C2355723C3D320DE289ADA4EAEXMSGC332eu_
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=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.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/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.com/sharepoint/dsp" xmlns:udc=3D"http://schemas.microsoft.com/data/udc"=
 xmlns:xsd=3D"http://www.w3.org/2001/XMLSchema" xmlns:sp=3D"http://schemas.=
microsoft.com/sharepoint/" xmlns:sps=3D"http://schemas.microsoft.com/sharep=
oint/soap/" xmlns:xsi=3D"http://www.w3.org/2001/XMLSchema-instance" xmlns:u=
dcxf=3D"http://schemas.microsoft.com/data/udc/xmlfile" xmlns:wf=3D"http://s=
chemas.microsoft.com/sharepoint/soap/workflow/" xmlns:mver=3D"http://schema=
s.openxmlformats.org/markup-compatibility/2006" xmlns:m=3D"http://schemas.m=
icrosoft.com/office/2004/12/omml" xmlns:mrels=3D"http://schemas.openxmlform=
ats.org/package/2006/relationships" xmlns:ex12t=3D"http://schemas.microsoft=
.com/exchange/services/2006/types" xmlns:ex12m=3D"http://schemas.microsoft.=
com/exchange/services/2006/messages" xmlns=3D"http://www.w3.org/TR/REC-html=
40">

<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:"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;}
 /* 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;}
-->
</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 set the agenda for the Phil=
adelphia
PKIX meeting.<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>Anyone wanting a slot should send m=
e an
e-mail as soon as possible, no later than EOD Wednesday next week (Feb 27).=
<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>As usual I want the lead editor for=
 every current
pkix draft to tell me if they want a slot or not.<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>We are currently scheduled as a Mon=
day
morning session from 0900-1130, which means two things.<o:p></o:p></span></=
p>

<p class=3DMsoNormal><span lang=3DEN-US>1) We have 2.5 hours available whic=
h should
be plenty of time.<o:p></o:p></span></p>

<p class=3DMsoNormal><span lang=3DEN-US>2) We need to have everything set, =
including
presentations sent to me by Sunday night.<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_9F11911AED01D24BAA1C2355723C3D320DE289ADA4EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1KBknYL090068 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 04:46:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1KBknwX090065; Wed, 20 Feb 2008 04:46:49 -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.13.5/8.13.5) with ESMTP id m1KBkhUl090033 for <[e-mail]>; Wed, 20 Feb 2008 04:46:47 -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 MAA46666 for <[e-mail]>; Wed, 20 Feb 2008 12:55:54 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008022012464196:53998 ; Wed, 20 Feb 2008 12:46:41 +0100 
Date: Wed, 20 Feb 2008 12:46:39 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 20/02/2008 12:46:41, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 20/02/2008 12:46:42, Serialize complete at 20/02/2008 12:46:42
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl,

We both agree that specifying the format is the major goal. 
However the current text does not say it yet.

The concept of TA is defined in RFC 3280 and since 3280bis will be soon issued, 
it will not be changed before many years.

It is not possible to use the same name, i.e. TA, with two different meanings.

So you should use a different name for a "TA with associated data".
For the time being let us call it TAAD.   

A TA Store is not simply an addition of TAADs. 
Some additional data may apply for all TAADs present in given TAS (TA Store).
Let us call it for the time being: TASAD.

The content of a TAS may then be modelized as: TASAD + sigma (TAAD)

With this model in mind, I would agree that it is possible 
to add or remove a TAAD as a whole.

We will have to identify what kind of data can be associated with a TAS 
and what kind of data can be associated with a TA. 

Do you agree with the above concepts 
(leaving aside the terminology that can be changed) ? 

Now, let me address two minor points:

I am still not sure what you have in mind when you say:

[CRW] This requirement does not relate to push or pull.  The language
should be improved to indicate the intent is to limit the intended
recipients (i.e., target trust stores).

Would you be able to elaborate, or provide an example for pull ?

Finally, to answer your question:

 - the fact that constraints that influence certification path
   validation may be understood either as constraints that allow 
   to build a certification path or also as constraints that allow 
   to make sure that none of the certificates from the certification 
   path are revoked

   using some timeliness indicators.

[CRW] I'm not sure what this means.

Giving an example, this means that the OCSP response in a cache 
may only be 2 hours old, or that a new CRL shall be fetched 
if the one that is in the cache is older than 2 hours.

Denis

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

>Comments inline...
>
><snip>
>This draft redefines "trust anchors" in a way that is not compatible
>with RFC 3280. RFC 3280 does not contain a formal definition of a trust
>anchor, but contains the following sentences:
>
>The trust anchor information includes:
>
>   (1)  the trusted issuer name,
>
>   (2)  the trusted public key algorithm,
>
>   (3)  the trusted public key, and
>
>   (4)  optionally, the trusted public key parameters associated
>        with the public key.
>
>It also states:
>
>   Valid paths begin with certificates issued by a trust anchor.
>   The algorithm requires the public key of the CA, the CA's name, 
>   and any constraints upon the set of paths that may be validated 
>   using this key.
>
>This draft states:
>
>   Trust Anchor: A trust anchor is an authoritative entity represented
>   via a public key and associated data. (...) 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 makes a big difference. 
>
>In this draft, the trust anchor would include "constraints expressed in
>the associated data for the trust anchor", whereas RFC 3280 considers
>that these constraints are external to the trust anchor information.
>
>[CRW] This difference is intentional, as RFC3280 is only one context
>addressed for TA mgmt.    
>
><snip>
>
>Let us start from the beginning: an application needs to validate some
>public key certificates and for doing this will have to use data
>contained in at least one Trust Anchor Store which contains one or more
>sets of trust anchor *and additional data*.
>
>[CRW] A more general starting point would be signature verification,
>since validating public key certificates is only one example.
>
>A "Trust Anchor Store manager" (that is different from the notion of "TA
>manager" as defined in the draft) may need to change or update the
>content of a given Trust Anchor Store. 
>
>[CRW] Perhaps the "TA Manager" definition in the draft should be "TA
>Store Manager" since they are referring to the same role.
>
>The content of a Trust Anchor Store equals to a validation policy. 
>Validation policies may be rather complex, so the very first requirement
>is to be able to define or change the content of a Trust Anchor Store
>*as a whole*.
>
>[CRW] I could see this either way but replacing an entire store to
>change one bit in one TA may be too inefficient in some scenarios.
>Maybe there's an additional requirement to support whole store
>replacement, but that doesn't seem appropriate as the only mechanism.
>
>It is very doubtful that *updates* to a Trust Anchor Store would be
>feasible. 
>The current draft makes the assumption that it would. 
>
>[CRW] Why is this so?  Current means don't require replacing an entire
>store to add or remove a single TA.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>    At a minimum, it [a general-purpose solution] must enable 
>    a trust anchor manager to discovery which TA stores are present, 
>    to add trust anchors to, remove trust anchors from, and determine 
>    which trust anchors are installed in a particular trust anchor
>store.
>
>A Trust Anchor Store manager may need to change data in the Trust Anchor
>Store that is not associated with one TA itself. For example, it may
>decide that OCSP responses shall be used, or that CRLs shall be used, or
>that a new CRL shall be fetched if a CRL in the cache is older that 2
>hours, or that delta-CRLs shall be used, etc ... This requirement may be
>different for every level of the certification tree or in the
>certification forest. 
>This kind of requirement is fully missing in the current draft.
>
>[CRW] Revocation sources could be an additional form of constraint.
>That seems reasonable.
>
>Whatever the certification tree is, a Trust Anchor Store manager may
>also decide to use leaf certificates that contain a particular
>extension, e.g.
>which mentions that it is a qualified certificate. This kind of concept
>is a property associated data contained in a Trust Anchor Store.
>
>[CRW] OK.
>
>The draft considers that each trust anchor is associated with a "scope
>of authority" "(e.g., a trust anchor public key may be limited to
>verification of firmware updates only), or more general (such as to
>validate certification paths for certificates issued to users or
>devices)", whereas the picture is fully inversed: a given "scope of
>authority" 
>will accept one or more trust anchors *and additional data*.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   Trust anchors may be explicitly authorized for a limited set of
>purposes.
>
>
>The major problem with this draft is that it places Trust Anchors at the
>top of the hierarchy, whereas Trust Anchor Stores are at the top. 
>
>[CRW] This relates to a discussion on the TAM list regarding requiring
>different trust anchor store managers with different privileges to
>manage different trust anchor stores.  Addressing that requirement may
>solve the hierarchy problem you are citing.
>
>Using the vocabulary defined in RFC 5055, each Trust Anchor Store
>contains one "validation policy".
>
>This means that it is the responsibility of the Trust Anchor Store
>manager to define which trust anchors shall be used and which additional
>data shall be associated with it.
>
>The current draft is mandating the existence of a *single* protocol to
>"push" 
>information to the Trust Anchor Stores. It is much more important to
>specify the format of the information that will be pushed and to leave
>the details for pushing it to the local OS or to a management
>application.
>
>[CRW] Specifying the format is the goal.  The draft mandates neither
>push nor pull.
>
>The content of a Trust Anchor Store should be formatted while being
>transferred, so that it can be locally interpreted without any
>ambiguity. 
>
>This allows pulling the formatted data.
>
>[CRW] Agree.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   A protocol for TA management must allow a TA management 
>   transaction, to be directed to all TA stores for which the manager 
>   is responsible, targeted to an enumerated list of one or more
>   groups of trust anchor stores, or targeted to an individual trust
>   anchor store. 
>
>[CRW] This requirement does not relate to push or pull.  The language
>should be improved to indicate the intent is to limit the intended
>recipients (i.e., target trust stores).
>
>"Discovering which trust anchors installed in a particular trust anchor
>store" 
>is not an interesting requirement. Knowing that a given store contains
>four trust anchors does not help, since the additional data that places
>constraints both on the way to build the certification tree and *the way
>to check that none of the certificates from the certification tree is
>revoked* are not part of the information placed in a trust anchor.
>
>[CRW] TAs are defined as including the additional data (see your earlier
>objection).  Including revocation mechanism as a constraint seems fine
>to me.  
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   Despite the prevalent use of trust anchors, there is neither a
>   standard means for discovering which trust anchors installed in a
>   particular trust anchor store nor a standard means of managing those
>   trust anchors.
>
>The current draft is mandating the existence of a *single* protocol to
>"pull" 
>information from Trust Anchor Stores. It is more important to specify
>the format of the information that will be pulled and to leave the
>details for pulling it from the local OS or from a management
>application.
>
>[CRW] Specifying the format is the goal.  The draft mandates neither
>push nor pull.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   A trust anchor manager must be able to authenticate which device
>   produced a report listing the contents of a trust anchor store and,
>   be able to confirm the contents of the report have not been
>   subsequently altered.
>
>The document states:
>
>   A trust anchor definition should enable the representation of
>   constraints that influence certification path validation or otherwise
>   establish the scope of usage of the trust anchor public key.
>
>There are two problems with that sentence:
>
> - a vocabulary problem, since the current trust anchor definition 
>   does not include the constraints, and
>
>[CRW] The trust anchor definition in the draft does include the
>constraints.
>
> - the fact that constraints that influence certification path
>validation 
>   may be understood either as constraints that allow to build 
>   a certification path or also as constraints that allow to make sure 
>   that none of the certificates from the certification path are revoked
>
>   using some timeliness indicators.
>
>[CRW] I'm not sure what this means.
>
>Finally the security considerations section contains additional
>requirements (e.g. "it must be possible to authenticate the originator
>of a TA management transaction and confirm the authorization of the
>originator for that transaction", whereas it should only highlight some
>security issues.
>
>[CRW] This is going to be fixed.  The plan is to replace this draft with
>a requirements draft.  A problem statement isn't needed since this isn't
>a BOF.  We started to late to get a new -00 draft submitted before the
>deadline.
>
>RFC 3379 and RFC 5055 should be added to the informative references.
>
>[CRW] OK.
>
>Denis
>
>>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 Problem Statement
>>	Author(s)       : R. Reddy, C. Wallace
>>	Filename        :
>draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
>>	Pages           : 15
>>	Date            : 2008-02-18
>>
>>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 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 as well as problems that must be addressed by such a 
>>mechanism.  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-problem-sta
>>tement-01.txt
>>
>>To remove yourself from the I-D Announcement list, send a message to 
>>[e-mail] with the word unsubscribe in the body of 
>>the message.
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the 
>>username "anonymous" and a password of your e-mail address. After 
>>logging in, type "cd internet-drafts" and then
>>	"get draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>>
>>A list of Internet-Drafts directories can be found in 
>>http://www.ietf.org/shadow.html or 
>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>	[e-mail].
>>In the body type:
>>	"FILE
>/internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>>
>>NOTE:   The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>
>>Below is the data which will enable a MIME compliant mail reader 
>>implementation to automatically retrieve the ASCII version of the 
>>Internet-Draft.
>>
>>Content-Type: text/plain
>>Content-ID:     <[e-mail]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt







Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JMh7uK017656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 15:43:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1JMh7SO017655; Tue, 19 Feb 2008 15:43:07 -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.13.5/8.13.5) with SMTP id m1JMh6qx017647 for <[e-mail]>; Tue, 19 Feb 2008 15:43:07 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 6026 invoked from network); 19 Feb 2008 22:35:34 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;19 Feb 2008 22:35:34 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 19 Feb 2008 22:35:34 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Date: Tue, 19 Feb 2008 17:43:05 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Thread-Index: Achy+0YPrFoowytPS2aK7pVMxZemngASdRaQ
References: <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Denis Pinkas" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1JMh7qx017649
Sender: [e-mail]
Precedence: 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 inline...

<snip>
This draft redefines "trust anchors" in a way that is not compatible
with RFC 3280. RFC 3280 does not contain a formal definition of a trust
anchor, but contains the following sentences:

The trust anchor information includes:

   (1)  the trusted issuer name,

   (2)  the trusted public key algorithm,

   (3)  the trusted public key, and

   (4)  optionally, the trusted public key parameters associated
        with the public key.

It also states:

   Valid paths begin with certificates issued by a trust anchor.
   The algorithm requires the public key of the CA, the CA's name, 
   and any constraints upon the set of paths that may be validated 
   using this key.

This draft states:

   Trust Anchor: A trust anchor is an authoritative entity represented
   via a public key and associated data. (...) 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 makes a big difference. 

In this draft, the trust anchor would include "constraints expressed in
the associated data for the trust anchor", whereas RFC 3280 considers
that these constraints are external to the trust anchor information.

[CRW] This difference is intentional, as RFC3280 is only one context
addressed for TA mgmt.    

<snip>

Let us start from the beginning: an application needs to validate some
public key certificates and for doing this will have to use data
contained in at least one Trust Anchor Store which contains one or more
sets of trust anchor *and additional data*.

[CRW] A more general starting point would be signature verification,
since validating public key certificates is only one example.

A "Trust Anchor Store manager" (that is different from the notion of "TA
manager" as defined in the draft) may need to change or update the
content of a given Trust Anchor Store. 

[CRW] Perhaps the "TA Manager" definition in the draft should be "TA
Store Manager" since they are referring to the same role.

The content of a Trust Anchor Store equals to a validation policy. 
Validation policies may be rather complex, so the very first requirement
is to be able to define or change the content of a Trust Anchor Store
*as a whole*.

[CRW] I could see this either way but replacing an entire store to
change one bit in one TA may be too inefficient in some scenarios.
Maybe there's an additional requirement to support whole store
replacement, but that doesn't seem appropriate as the only mechanism.

It is very doubtful that *updates* to a Trust Anchor Store would be
feasible. 
The current draft makes the assumption that it would. 

[CRW] Why is this so?  Current means don't require replacing an entire
store to add or remove a single TA.

So I am challenging the fact that the following requirement should
apply:

    At a minimum, it [a general-purpose solution] must enable 
    a trust anchor manager to discovery which TA stores are present, 
    to add trust anchors to, remove trust anchors from, and determine 
    which trust anchors are installed in a particular trust anchor
store.

A Trust Anchor Store manager may need to change data in the Trust Anchor
Store that is not associated with one TA itself. For example, it may
decide that OCSP responses shall be used, or that CRLs shall be used, or
that a new CRL shall be fetched if a CRL in the cache is older that 2
hours, or that delta-CRLs shall be used, etc ... This requirement may be
different for every level of the certification tree or in the
certification forest. 
This kind of requirement is fully missing in the current draft.

[CRW] Revocation sources could be an additional form of constraint.
That seems reasonable.

Whatever the certification tree is, a Trust Anchor Store manager may
also decide to use leaf certificates that contain a particular
extension, e.g.
which mentions that it is a qualified certificate. This kind of concept
is a property associated data contained in a Trust Anchor Store.

[CRW] OK.

The draft considers that each trust anchor is associated with a "scope
of authority" "(e.g., a trust anchor public key may be limited to
verification of firmware updates only), or more general (such as to
validate certification paths for certificates issued to users or
devices)", whereas the picture is fully inversed: a given "scope of
authority" 
will accept one or more trust anchors *and additional data*.

So I am challenging the fact that the following requirement should
apply:

   Trust anchors may be explicitly authorized for a limited set of
purposes.


The major problem with this draft is that it places Trust Anchors at the
top of the hierarchy, whereas Trust Anchor Stores are at the top. 

[CRW] This relates to a discussion on the TAM list regarding requiring
different trust anchor store managers with different privileges to
manage different trust anchor stores.  Addressing that requirement may
solve the hierarchy problem you are citing.

Using the vocabulary defined in RFC 5055, each Trust Anchor Store
contains one "validation policy".

This means that it is the responsibility of the Trust Anchor Store
manager to define which trust anchors shall be used and which additional
data shall be associated with it.

The current draft is mandating the existence of a *single* protocol to
"push" 
information to the Trust Anchor Stores. It is much more important to
specify the format of the information that will be pushed and to leave
the details for pushing it to the local OS or to a management
application.

[CRW] Specifying the format is the goal.  The draft mandates neither
push nor pull.

The content of a Trust Anchor Store should be formatted while being
transferred, so that it can be locally interpreted without any
ambiguity. 

This allows pulling the formatted data.

[CRW] Agree.

So I am challenging the fact that the following requirement should
apply:

   A protocol for TA management must allow a TA management 
   transaction, to be directed to all TA stores for which the manager 
   is responsible, targeted to an enumerated list of one or more
   groups of trust anchor stores, or targeted to an individual trust
   anchor store. 

[CRW] This requirement does not relate to push or pull.  The language
should be improved to indicate the intent is to limit the intended
recipients (i.e., target trust stores).

"Discovering which trust anchors installed in a particular trust anchor
store" 
is not an interesting requirement. Knowing that a given store contains
four trust anchors does not help, since the additional data that places
constraints both on the way to build the certification tree and *the way
to check that none of the certificates from the certification tree is
revoked* are not part of the information placed in a trust anchor.

[CRW] TAs are defined as including the additional data (see your earlier
objection).  Including revocation mechanism as a constraint seems fine
to me.  

So I am challenging the fact that the following requirement should
apply:

   Despite the prevalent use of trust anchors, there is neither a
   standard means for discovering which trust anchors installed in a
   particular trust anchor store nor a standard means of managing those
   trust anchors.

The current draft is mandating the existence of a *single* protocol to
"pull" 
information from Trust Anchor Stores. It is more important to specify
the format of the information that will be pulled and to leave the
details for pulling it from the local OS or from a management
application.

[CRW] Specifying the format is the goal.  The draft mandates neither
push nor pull.

So I am challenging the fact that the following requirement should
apply:

   A trust anchor manager must be able to authenticate which device
   produced a report listing the contents of a trust anchor store and,
   be able to confirm the contents of the report have not been
   subsequently altered.

The document states:

   A trust anchor definition should enable the representation of
   constraints that influence certification path validation or otherwise
   establish the scope of usage of the trust anchor public key.

There are two problems with that sentence:

 - a vocabulary problem, since the current trust anchor definition 
   does not include the constraints, and

[CRW] The trust anchor definition in the draft does include the
constraints.

 - the fact that constraints that influence certification path
validation 
   may be understood either as constraints that allow to build 
   a certification path or also as constraints that allow to make sure 
   that none of the certificates from the certification path are revoked

   using some timeliness indicators.

[CRW] I'm not sure what this means.

Finally the security considerations section contains additional
requirements (e.g. "it must be possible to authenticate the originator
of a TA management transaction and confirm the authorization of the
originator for that transaction", whereas it should only highlight some
security issues.

[CRW] This is going to be fixed.  The plan is to replace this draft with
a requirements draft.  A problem statement isn't needed since this isn't
a BOF.  We started to late to get a new -00 draft submitted before the
deadline.

RFC 3379 and RFC 5055 should be added to the informative references.

[CRW] OK.

Denis

>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 Problem Statement
>	Author(s)       : R. Reddy, C. Wallace
>	Filename        :
draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
>	Pages           : 15
>	Date            : 2008-02-18
>
>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 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 as well as problems that must be addressed by such a 
>mechanism.  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-problem-sta
>tement-01.txt
>
>To remove yourself from the I-D Announcement list, send a message to 
>[e-mail] with the word unsubscribe in the body of 
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then
>	"get draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>
>A list of Internet-Drafts directories can be found in 
>http://www.ietf.org/shadow.html or 
>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[e-mail].
>In the body type:
>	"FILE
/internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail
readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader 
>implementation to automatically retrieve the ASCII version of the 
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt






Received: from host51-202-static.61-88-b.business.telecomitalia.it (host51-202-static.61-88-b.business.telecomitalia.it [88.61.202.51]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JF5Yiu064695 for <[e-mail]>; Tue, 19 Feb 2008 08:05:40 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000f01c87308$e3d26c10$33ca3d58@privatocwklsr1>
From: "SIARHEI Grassetti" <[e-mail]>
To: [e-mail]
Subject: Your throbbing missile is ready to fire
Date: Tue, 19 Feb 2008 16:05:39 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C87311.4596D410"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000B_01C87311.4596D410
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Feel the power of your new tool
----------=_NextPart_000_000B_01C87311.4596D410
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.flareboxes.com/">Feel the power of your new=20
tool</A></BODY></HTML>
----------=_NextPart_000_000B_01C87311.4596D410--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JEB4r4058019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 07:11:04 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1JEB3wu058018; Tue, 19 Feb 2008 07:11:04 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from people.com.cn ([202.99.23.227]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1JEB13f058002 for <[e-mail]>; Tue, 19 Feb 2008 07:11:02 -0700 (MST) (envelope-from [e-mail])
Received: from people.com.cn([127.0.0.1]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm247bb5f35; Tue, 19 Feb 2008 22:24:25 +0800
Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id jm347b6542d; Sat, 16 Feb 2008 04:24:09 +0800
Received: from mail.ietf.org([64.170.98.32]) by people.com.cn(AIMC 2.9.5.8) with SMTP id AISP action; Sat, 16 Feb 2008 04:24:08 +0800
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 776C928D3DC; Fri, 15 Feb 2008 12:06:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4Jnq72k-7uh; Fri, 15 Feb 2008 12:06:30 -0800 (PST)
Received: from core3.amsl.com (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464E428D33D; Fri, 15 Feb 2008 12:04:43 -0800 (PST)
X-Original-To: [e-mail]
Delivered-To: [e-mail]
Received: by core3.amsl.com (Postfix, from userid 30) id D303528D24F; Fri, 15 Feb 2008 12:04:41 -0800 (PST)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key  Infrastructure Certificate and Certificate Revocation List (CRL)  Profile' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Fri, 15 Feb 2008 12:04:41 -0800 (PST)
Cc: pkix mailing list <[e-mail]>, pkix chair <[e-mail]>, Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>
X-BeenThere: [e-mail]
X-Mailman-Version: 2.1.9
List-Id: <ietf-announce.ietf.org>
List-Unsubscribe: <http://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=unsubscribe>
List-Post: <mailto:[e-mail]>
List-Help: <mailto:[e-mail]?subject=help>
List-Subscribe: <http://www.ietf.org/mailman/listinfo/ietf-announce>, <mailto:[e-mail]?subject=subscribe>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-AIMC-AUTH: (null)
X-AIMC-MAILFROM: [e-mail]
X-Auto-Forward: [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>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Certificate and Certificate 
   Revocation List (CRL) Profile '
   <draft-ietf-pkix-rfc3280bis-11.txt> as a Proposed Standard

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

The IESG contact persons are Sam Hartman and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-11.txt

Technical Summary
 
   This document is a replacement for RFC 3280, the standard that
   profiles X.509 certificate and CRL syntax for use in the IETF. RFC
   3280 needed to be updated to track IETF support for internationalized
   names, to correct errors that have been discovered since the
   publication of 3280 five years ago. As part of the update, the
   specification of the AIA certificate extension (an IETF "private"
   extension) was incorporated into the document, instead of being a
   standalone RFC. (4325). The document also updates the reference to the
   list of supported algorithms used with certificates. The authors made
   a minor modification to the text to make clear that hash algorithms
   other than SHA-1 can be used in certain places, consistent with
   Security Area policy to make all of our standards independent of
   specific hash algorithms. The security considerations section was
   expanded, to cal attention to more subtle (DoS) concerns that may
   arise in some contexts. Despite the numerous tweaks and fixes,  most
   of the text in this document is unchanged form 3280. The end of the
   introduction section  of this document clearly summarizes the
   differences between it and RFC 3280.

 
Working Group Summary
 
   The working group had consensus to advance this specification as a
proposed standard.
 
Protocol Quality
 
   This specification was reviewed for the IESG by Sam Hartman.

_______________________________________________
IETF-Announce mailing list
[e-mail]
http://www.ietf.org/mailman/listinfo/ietf-announce



Received: from [86.56.99.14] ([86.56.99.14]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JDmKpB054398 for <[e-mail]>; Tue, 19 Feb 2008 06:48:23 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000e01c872fe$1a9e22d0$0e633856@familypc>
From: "Mimi krystek" <[e-mail]>
To: [e-mail]
Subject: Want to have the best sex of your life? Here's how
Date: Tue, 19 Feb 2008 14:48:27 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000A_01C87306.7C6040E0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000A_01C87306.7C6040E0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Increase your thickness, enlarge your width, and change your sex life =
forever
----------=_NextPart_000_000A_01C87306.7C6040E0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.ferinetui.com/">Increase your thickness, enlarge =
your width,=20
and change your sex life forever</A></BODY></HTML>
----------=_NextPart_000_000A_01C87306.7C6040E0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1JD4JLS048426 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 19 Feb 2008 06:04:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1JD4Jwp048425; Tue, 19 Feb 2008 06:04:19 -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.13.5/8.13.5) with ESMTP id m1JD4GjN048408 for <[e-mail]>; Tue, 19 Feb 2008 06:04:17 -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 OAA60498 for <[e-mail]>; Tue, 19 Feb 2008 14:13:23 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008021914035635:23820 ; Tue, 19 Feb 2008 14:03:56 +0100 
Date: Tue, 19 Feb 2008 14:03:52 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 19/02/2008 14:03:56, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 19/02/2008 14:04:13, Serialize complete at 19/02/2008 14:04:13
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This draft redefines "trust anchors" in a way that is 
not compatible with RFC 3280. RFC 3280 does not contain 
a formal definition of a trust anchor, but contains 
the following sentences:

The trust anchor information includes:

   (1)  the trusted issuer name,

   (2)  the trusted public key algorithm,

   (3)  the trusted public key, and

   (4)  optionally, the trusted public key parameters associated
        with the public key.

It also states:

   Valid paths begin with certificates issued by a trust anchor.
   The algorithm requires the public key of the CA, the CA's name, 
   and any constraints upon the set of paths that may be validated 
   using this key.

This draft states:

   Trust Anchor: A trust anchor is an authoritative entity represented
   via a public key and associated data. (...) 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 makes a big difference. 

In this draft, the trust anchor would include "constraints expressed 
in the associated data for the trust anchor", whereas RFC 3280 considers 
that these constraints are external to the trust anchor information.

The whole document is focusing on trust anchors, but the basic notion 
that is being used is flawed.

Let us start from the beginning: an application needs to validate 
some public key certificates and for doing this will have to use 
data contained in at least one Trust Anchor Store which contains 
one or more sets of trust anchor *and additional data*.

A "Trust Anchor Store manager" (that is different from the notion 
of "TA manager" as defined in the draft) may need to change or update 
the content of a given Trust Anchor Store. 

The content of a Trust Anchor Store equals to a validation policy. 
Validation policies may be rather complex, so the very first requirement 
is to be able to define or change the content of a Trust Anchor Store 
*as a whole*.

It is very doubtful that *updates* to a Trust Anchor Store would be feasible. 
The current draft makes the assumption that it would. 

So I am challenging the fact that the following requirement should apply:

    At a minimum, it [a general-purpose solution] must enable 
    a trust anchor manager to discovery which TA stores are present, 
    to add trust anchors to, remove trust anchors from, and determine 
    which trust anchors are installed in a particular trust anchor store.

A Trust Anchor Store manager may need to change data in the Trust Anchor Store 
that is not associated with one TA itself. For example, it may decide that 
OCSP responses shall be used, or that CRLs shall be used, or that a new CRL 
shall be fetched if a CRL in the cache is older that 2 hours, or that 
delta-CRLs shall be used, etc ... This requirement may be different for 
every level of the certification tree or in the certification forest. 
This kind of requirement is fully missing in the current draft.

Whatever the certification tree is, a Trust Anchor Store manager may also 
decide to use leaf certificates that contain a particular extension, 
e.g. which mentions that it is a qualified certificate. This kind of concept 
is a property associated data contained in a Trust Anchor Store.

The draft considers that each trust anchor is associated with 
a "scope of authority" "(e.g., a trust anchor public key may be limited 
to verification of firmware updates only), or more general (such as to validate 
certification paths for certificates issued to users or devices)", 
whereas the picture is fully inversed: a given "scope of authority" 
will accept one or more trust anchors *and additional data*.

So I am challenging the fact that the following requirement should apply:

   Trust anchors may be explicitly authorized for a limited set of purposes. 

The major problem with this draft is that it places Trust Anchors at the top 
of the hierarchy, whereas Trust Anchor Stores are at the top. 
Using the vocabulary defined in RFC 5055, each Trust Anchor Store contains 
one "validation policy".

This means that it is the responsibility of the Trust Anchor Store manager 
to define which trust anchors shall be used and which additional data 
shall be associated with it.

The current draft is mandating the existence of a *single* protocol to "push" 
information to the Trust Anchor Stores. It is much more important to specify 
the format of the information that will be pushed and to leave the details 
for pushing it to the local OS or to a management application.

The content of a Trust Anchor Store should be formatted while being transferred,
so that it can be locally interpreted without any ambiguity. 

This allows pulling the formatted data.

So I am challenging the fact that the following requirement should apply:

   A protocol for TA management must allow a TA management 
   transaction, to be directed to all TA stores for which the manager 
   is responsible, targeted to an enumerated list of one or more
   groups of trust anchor stores, or targeted to an individual trust
   anchor store. 

"Discovering which trust anchors installed in a particular trust anchor store" 
is not an interesting requirement. Knowing that a given store contains 
four trust anchors does not help, since the additional data that places 
constraints both on the way to build the certification tree and *the way 
to check that none of the certificates from the certification tree is revoked* 
are not part of the information placed in a trust anchor.

So I am challenging the fact that the following requirement should apply:

   Despite the prevalent use of trust anchors, there is neither a
   standard means for discovering which trust anchors installed in a
   particular trust anchor store nor a standard means of managing those
   trust anchors.

The current draft is mandating the existence of a *single* protocol to "pull" 
information from Trust Anchor Stores. It is more important to specify the format 
of the information that will be pulled and to leave the details for pulling it 
from the local OS or from a management application.

So I am challenging the fact that the following requirement should apply:

   A trust anchor manager must be able to authenticate which device
   produced a report listing the contents of a trust anchor store and,
   be able to confirm the contents of the report have not been
   subsequently altered.

The document states:

   A trust anchor definition should enable the representation of
   constraints that influence certification path validation or otherwise
   establish the scope of usage of the trust anchor public key.

There are two problems with that sentence:

 - a vocabulary problem, since the current trust anchor definition 
   does not include the constraints, and

 - the fact that constraints that influence certification path validation 
   may be understood either as constraints that allow to build 
   a certification path or also as constraints that allow to make sure 
   that none of the certificates from the certification path are revoked 
   using some timeliness indicators.

Finally the security considerations section contains additional requirements 
(e.g. "it must be possible to authenticate the originator of a TA management 
transaction and confirm the authorization of the originator for that transaction", 
whereas it should only highlight some security issues.

RFC 3379 and RFC 5055 should be added to the informative references.

Denis

>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 Problem Statement
>	Author(s)       : R. Reddy, C. Wallace
>	Filename        : draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
>	Pages           : 15
>	Date            : 2008-02-18
>
>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 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 as well as problems that must be addressed by
>such a mechanism.  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-problem-statement-01.txt
>
>To remove yourself from the I-D Announcement list, send a message to
>[e-mail] with the word unsubscribe in the body of 
>the message.
>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>to change your subscription settings.
>
>Internet-Drafts are also available by anonymous FTP. Login with the 
>username "anonymous" and a password of your e-mail address. After 
>logging in, type "cd internet-drafts" and then
>	"get draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>
>A list of Internet-Drafts directories can be found in
>http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>
>Internet-Drafts can also be obtained by e-mail.
>
>Send a message to:
>	[e-mail].
>In the body type:
>	"FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>
>NOTE:   The mail server at ietf.org can return the document in
>	MIME-encoded form by using the "mpack" utility.  To use this
>	feature, insert the command "ENCODING mime" before the "FILE"
>	command.  To decode the response(s), you will need "munpack" or
>	a MIME-compliant mail reader.  Different MIME-compliant mail readers
>	exhibit different behavior, especially when dealing with
>	"multipart" MIME messages (i.e. documents which have been split
>	up into multiple messages), so check your local documentation on
>	how to manipulate these messages.
>
>Below is the data which will enable a MIME compliant mail reader
>implementation to automatically retrieve the ASCII version of the
>Internet-Draft.
>
>Content-Type: text/plain
>Content-ID:     <[e-mail]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt






Received: from [12.148.137.130] ([12.148.137.130]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1J1kOsl080914 for <[e-mail]>; Mon, 18 Feb 2008 18:46:24 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c87299$4dd952b0$8289940c@JLAWLER>
From: "gracie Decato" <[e-mail]>
To: [e-mail]
Subject: Want to be longer, thicker and harder all night long? Here's how
Date: Mon, 18 Feb 2008 19:46:54 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C87267.033EE2B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0006_01C87267.033EE2B0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

it's normal to be ashamed if you have a small sch1ong, but CHANGE THAT =
around today
----------=_NextPart_000_0006_01C87267.033EE2B0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.terahimben.com/">it's normal to be ashamed if you =
have a=20
small sch1ong, but CHANGE THAT around today</A></BODY></HTML>
----------=_NextPart_000_0006_01C87267.033EE2B0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1IFF0Wj018922 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 18 Feb 2008 08:15:00 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1IFF0qY018920; Mon, 18 Feb 2008 08:15:00 -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.13.5/8.13.5) with ESMTP id m1IFExoY018908 for <[e-mail]>; Mon, 18 Feb 2008 08:15:00 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 84E143A6C59; Mon, 18 Feb 2008 07:15:01 -0800 (PST)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt 
Message-Id: <[e-mail]>
Date: Mon, 18 Feb 2008 07:15:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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 Problem Statement
	Author(s)       : R. Reddy, C. Wallace
	Filename        : draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
	Pages           : 15
	Date            : 2008-02-18

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 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 as well as problems that must be addressed by
such a mechanism.  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-problem-statement-01.txt

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

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

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

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

Send a message to:
	[e-mail].
In the body type:
	"FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".

NOTE:   The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

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

Content-Type: text/plain
Content-ID:     <2008-02-18070750.I-D\@ietf.org>

--OtherAccess--

--NextPart--



Received: from [80.51.49.16] ([80.51.49.16]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1IAYnKY094132 for <[e-mail]>; Mon, 18 Feb 2008 03:34:51 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000c01c87219$e6f84bc0$10313350@sekretariat>
From: "Kolonitskiy Leon" <[e-mail]>
To: [e-mail]
Subject: Your best present to her is your long hard rod.
Date: Mon, 18 Feb 2008 11:34:55 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C87222.48BCB3C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080217-0, 2008-02-17), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0008_01C87222.48BCB3C0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

The power within you is about to be unleashed.
----------=_NextPart_000_0008_01C87222.48BCB3C0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.kineticen.com/">The power within you is about to =
be=20
unleashed.</A></BODY></HTML>
----------=_NextPart_000_0008_01C87222.48BCB3C0--


Received: from pd9569f19.dip0.t-ipconnect.de (pd9569f19.dip0.t-ipconnect.de [217.86.159.25]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1I6lJOI077345 for <[e-mail]>; Sun, 17 Feb 2008 23:47:24 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c871fa$154e6100$199f56d9@PC01>
From: "Joost Krishnan" <[e-mail]>
To: [e-mail]
Subject: Those locker room stares will be for the right reason.
Date: Mon, 18 Feb 2008 07:47:09 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C87202.7712C900"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0003_01C87202.7712C900
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Do you lust for that elusive dream girl? Get her now with this.
----------=_NextPart_000_0003_01C87202.7712C900
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.feriasid.com/">Do you lust for that elusive dream =
girl? Get=20
her now with this.</A></BODY></HTML>
----------=_NextPart_000_0003_01C87202.7712C900--


Received: from [81.144.132.74] ([81.144.132.74]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1H9vn6P087749 for <[e-mail]>; Sun, 17 Feb 2008 02:58:00 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000c01c8714b$93e2a850$4a849051@paullaptop>
From: "abi raps" <[e-mail]>
To: [e-mail]
Subject: Want the women to crave for you? Make sure you have a hot, large rod in your pants.
Date: Sun, 17 Feb 2008 09:57:59 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C8714B.93E05E60"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080216-0, 16/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0008_01C8714B.93E05E60
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Having a small pen1s affects your outlook on life, your confidence and =
your attitude. With this remedy, you can add inches in just weeks.
----------=_NextPart_000_0008_01C8714B.93E05E60
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.rheueneston.com/">Having a small pen1s affects =
your outlook=20
on life, your confidence and your attitude. With this remedy, you can =
add inches=20
in just weeks.</A></BODY></HTML>
----------=_NextPart_000_0008_01C8714B.93E05E60--


Received: from host127-106-static.119-81-b.business.telecomitalia.it (host127-106-static.119-81-b.business.telecomitalia.it [81.119.106.127]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1H4PEFP070719 for <[e-mail]>; Sat, 16 Feb 2008 21:25:16 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000901c8711d$5d7b2180$7f6a7751@dsga>
From: "jure Engqvist" <[e-mail]>
To: [e-mail]
Subject: Let her choose between a rock and a hard DlCK...
Date: Sun, 17 Feb 2008 05:27:11 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0005_01C87125.BF3F8980"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0005_01C87125.BF3F8980
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Want a tool in your pants that's the size of a power drill? now you can.
----------=_NextPart_000_0005_01C87125.BF3F8980
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.chronespe.com/">Want a tool in your pants that's =
the size of=20
a power drill? now you can.</A></BODY></HTML>
----------=_NextPart_000_0005_01C87125.BF3F8980--


Received: from cpc1-cmbg10-0-0-cust752.cmbg.cable.ntl.com (cpc1-cmbg10-0-0-cust752.cmbg.cable.ntl.com [81.102.134.241]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1GJt8vx034493 for <[e-mail]>; Sat, 16 Feb 2008 12:55:13 -0700 (MST) (envelope-from iun'[e-mail])
Message-ID: <000d01c870d5$d28c3c90$f1866651@home76f34f7ae9>
From: "addison Forte" <iun'[e-mail]>
To: [e-mail]
Subject: Want the women to crave for you? Make sure you have a hot, large rod in your pants.
Date: Sat, 16 Feb 2008 19:55:04 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C870D5.D28C3C90"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0009_01C870D5.D28C3C90
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Live the life of a casanova when you add 3 inches to an already massive =
sch1ong.
----------=_NextPart_000_0009_01C870D5.D28C3C90
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.onnermokele.com/">Live the life of a casanova when =
you add 3=20
inches to an already massive sch1ong.</A></BODY></HTML>
----------=_NextPart_000_0009_01C870D5.D28C3C90--


Received: from [58.181.249.244] ([203.107.142.97]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1G5CrUr068966 for <[e-mail]>; Fri, 15 Feb 2008 22:13:05 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c8705a$afc4ffb0$f4f9b53a@JEAB>
From: "Khamsone Piatek" <[e-mail]>
To: [e-mail]
Subject: Ashamed or concerned about the size of your tool? Don't be - you can add inches today.
Date: Sat, 16 Feb 2008 12:13:37 +0700
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C87095.5C23D7B0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0009_01C87095.5C23D7B0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You KNOW when the girls start staring at your pants, you're doing =
something right.
----------=_NextPart_000_0009_01C87095.5C23D7B0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.vialared.com/">You KNOW when the girls start =
staring at your=20
pants, you're doing something right.</A></BODY></HTML>
----------=_NextPart_000_0009_01C87095.5C23D7B0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1G4plJX067689 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 21:51:47 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1G4plaE067688; Fri, 15 Feb 2008 21:51:47 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1G4pkjJ067681 for <[e-mail]>; Fri, 15 Feb 2008 21:51:46 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.5.60]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1JQF1c-0008Ey-4U; Fri, 15 Feb 2008 23:51:44 -0500
Mime-Version: 1.0
Message-Id: <p06240500c3dc1b34bae3@[192.168.5.60]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 15 Feb 2008 23:48:00 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
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 5:37 PM +1300 2/16/08, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>>At 2:14 AM +1300 2/16/08, Peter Gutmann wrote:
>>>Stephen Kent <[e-mail]> writes:
>>>>RFC 3280, which superseded 2459, removed the reference to 
>>>>wildcard characters
>>>>in SANs, making it clear that they were no longer acceptable.  3280 was
>>>>published in 2002, 5.5 years ago.
>>>
>>>Now all we need to do is convince every CA on the planet to stop issuing
>>>wildcard certificates.  Who wants to have a go first?
>>
>>not EVERY CA issues such certs. since the notification problem is thus not
>>nearly so great as you suggest, I'm willing to delegate this awesome
>>responsibility to you.
>
>Since I'm sure that convincing Verisign, Thawte, Godaddy, Digitrust, Geotrust
>and the rest of the world's CAs (along with vendors like Microsoft) to change
>their business models will be easier than getting a PKIX spec changed to
>approximate reality, I will indeed give that a go :-).
>
>Peter.

Peter,

It's that "can do" attitude that makes it a pleasure work with you :-).

BTW, I'm near you right now (at AKL, heading back from BNE to LAX). 
I can almost feel the love!

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1G4bJwI066994 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 21:37:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1G4bJPZ066993; Fri, 15 Feb 2008 21:37:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1G4bGWE066970 for <[e-mail]>; Fri, 15 Feb 2008 21:37:19 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 9002B183A2; Sat, 16 Feb 2008 17:37:15 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fzfvlih-VKkB; Sat, 16 Feb 2008 17:37:15 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 09CB318394; Sat, 16 Feb 2008 17:37:14 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id BD88FE080BD; Sat, 16 Feb 2008 17:37:11 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1JQEnX-0006L6-Ke; Sat, 16 Feb 2008 17:37:11 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: [e-mail], [e-mail]
In-Reply-To: <p06240506c3dbe36c40a5@[192.168.163.192]>
Message-Id: <[e-mail]>
Date: Sat, 16 Feb 2008 17:37:11 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:
>At 2:14 AM +1300 2/16/08, Peter Gutmann wrote:
>>Stephen Kent <[e-mail]> writes:
>>>RFC 3280, which superseded 2459, removed the reference to wildcard characters
>>>in SANs, making it clear that they were no longer acceptable.  3280 was
>>>published in 2002, 5.5 years ago.
>>
>>Now all we need to do is convince every CA on the planet to stop issuing
>>wildcard certificates.  Who wants to have a go first?
>
>not EVERY CA issues such certs. since the notification problem is thus not
>nearly so great as you suggest, I'm willing to delegate this awesome
>responsibility to you.

Since I'm sure that convincing Verisign, Thawte, Godaddy, Digitrust, Geotrust
and the rest of the world's CAs (along with vendors like Microsoft) to change
their business models will be easier than getting a PKIX spec changed to
approximate reality, I will indeed give that a go :-).

Peter.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1G0qN29050881 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 17:52:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1G0qNKf050880; Fri, 15 Feb 2008 17:52:23 -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.13.5/8.13.5) with ESMTP id m1G0qME7050873 for <[e-mail]>; Fri, 15 Feb 2008 17:52:22 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.163.192]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1JQBHr-00086U-6Q; Fri, 15 Feb 2008 19:52:18 -0500
Mime-Version: 1.0
Message-Id: <p06240506c3dbe36c40a5@[192.168.163.192]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Fri, 15 Feb 2008 19:52:06 -0500
To: [e-mail] (Peter Gutmann)
From: Stephen Kent <[e-mail]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
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 2:14 AM +1300 2/16/08, Peter Gutmann wrote:
>Stephen Kent <[e-mail]> writes:
>
>>RFC 3280, which superseded 2459, removed the reference to wildcard characters
>>in SANs, making it clear that they were no longer acceptable.  3280 was
>>published in 2002, 5.5 years ago.
>
>Now all we need to do is convince every CA on the planet to stop issuing
>wildcard certificates.  Who wants to have a go first?

not EVERY CA issues such certs. since the notification problem is 
thus not nearly so great as you suggest, I'm willing to delegate this 
awesome responsibility to you.

>
>>I agree that 2818 should be revised, given that the reference it makes to the
>>PKIX cert profile is now 2 revs (.5. years) out of date, and no longer valid.
>
>Perhaps 2818bis could contain a note for implementors mapping what the RFCs
>say to what the world really does.
>
>(I suspect it'd be quite a long note).

Since the real world is full of broken CA behavior, as you have 
personally document through a multi-year collection of non-compliant 
certs, a note explaining various degrees of brokenness would indeed 
be very long.  It also has no place in this document.  Maybe you 
should submit an April 1st RFC on the topic.

Steve



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1FK7nJZ030261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 13:07:49 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1FK7n6e030260; Fri, 15 Feb 2008 13: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 mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1FK7lot030254 for <[e-mail]>; Fri, 15 Feb 2008 13:07:48 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 30) id D303528D24F; Fri, 15 Feb 2008 12:04:41 -0800 (PST)
X-idtracker: yes
From: The IESG <[e-mail]>
To: IETF-Announce <[e-mail]>
Cc: Internet Architecture Board <[e-mail]>, RFC Editor <[e-mail]>, pkix mailing list <[e-mail]>, pkix chair <[e-mail]>
Subject: Protocol Action: 'Internet X.509 Public Key  Infrastructure Certificate and Certificate Revocation List (CRL)  Profile' to Proposed Standard 
Message-Id: <[e-mail]>
Date: Fri, 15 Feb 2008 12:04:41 -0800 (PST)
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

The IESG has approved the following document:

- 'Internet X.509 Public Key Infrastructure Certificate and Certificate 
   Revocation List (CRL) Profile '
   <draft-ietf-pkix-rfc3280bis-11.txt> as a Proposed Standard

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

The IESG contact persons are Sam Hartman and Tim Polk.

A URL of this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-rfc3280bis-11.txt

Technical Summary
 
   This document is a replacement for RFC 3280, the standard that
   profiles X.509 certificate and CRL syntax for use in the IETF. RFC
   3280 needed to be updated to track IETF support for internationalized
   names, to correct errors that have been discovered since the
   publication of 3280 five years ago. As part of the update, the
   specification of the AIA certificate extension (an IETF "private"
   extension) was incorporated into the document, instead of being a
   standalone RFC. (4325). The document also updates the reference to the
   list of supported algorithms used with certificates. The authors made
   a minor modification to the text to make clear that hash algorithms
   other than SHA-1 can be used in certain places, consistent with
   Security Area policy to make all of our standards independent of
   specific hash algorithms. The security considerations section was
   expanded, to cal attention to more subtle (DoS) concerns that may
   arise in some contexts. Despite the numerous tweaks and fixes,  most
   of the text in this document is unchanged form 3280. The end of the
   introduction section  of this document clearly summarizes the
   differences between it and RFC 3280.

 
Working Group Summary
 
   The working group had consensus to advance this specification as a
proposed standard.
 
Protocol Quality
 
   This specification was reviewed for the IESG by Sam Hartman.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1FDF9jM099364 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 15 Feb 2008 06:15:09 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1FDF9H4099363; Fri, 15 Feb 2008 06:15:09 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailhost.auckland.ac.nz (larry.its.auckland.ac.nz [130.216.12.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1FDF3Cm099352 for <[e-mail]>; Fri, 15 Feb 2008 06:15:08 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id 27EDB18414; Sat, 16 Feb 2008 02:15:03 +1300 (NZDT)
X-Virus-Scanned: by amavisd-new at mailhost.auckland.ac.nz
Received: from mailhost.auckland.ac.nz ([127.0.0.1]) by localhost (larry.its.auckland.ac.nz [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikMWeubfxjT0; Sat, 16 Feb 2008 02:15:03 +1300 (NZDT)
Received: from iris.cs.auckland.ac.nz (iris.cs.auckland.ac.nz [130.216.33.152]) by mailhost.auckland.ac.nz (Postfix) with ESMTP id F3D7518470; Sat, 16 Feb 2008 02:15:01 +1300 (NZDT)
Received: from wintermute01.cs.auckland.ac.nz (wintermute01.cs.auckland.ac.nz [130.216.34.38]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by iris.cs.auckland.ac.nz (Postfix) with ESMTP id 2E64519EC0B7; Sat, 16 Feb 2008 02:14:59 +1300 (NZDT)
Received: from pgut001 by wintermute01.cs.auckland.ac.nz with local (Exim 4.63) (envelope-from <[e-mail]>) id 1JQ0P5-0002sQ-3H; Sat, 16 Feb 2008 02:14:59 +1300
From: [e-mail] (Peter Gutmann)
To: [e-mail], [e-mail]
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: [e-mail]
In-Reply-To: <p06240502c3c5548ea417@[172.28.172.134]>
Message-Id: <[e-mail]>
Date: Sat, 16 Feb 2008 02:14:59 +1300
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent <[e-mail]> writes:

>RFC 3280, which superseded 2459, removed the reference to wildcard characters
>in SANs, making it clear that they were no longer acceptable.  3280 was
>published in 2002, 5.5 years ago.

Now all we need to do is convince every CA on the planet to stop issuing
wildcard certificates.  Who wants to have a go first?

>I agree that 2818 should be revised, given that the reference it makes to the
>PKIX cert profile is now 2 revs (.5. years) out of date, and no longer valid.

Perhaps 2818bis could contain a note for implementors mapping what the RFCs
say to what the world really does.

(I suspect it'd be quite a long note).

Peter.



Received: from 1408ds1-alb.0.fullrate.dk (1408ds1-alb.0.fullrate.dk [90.184.137.108]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1E4x0Rq069057 for <[e-mail]>; Wed, 13 Feb 2008 21:59:04 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c86ec6$502b3cd0$6c89b85a@acer47253a5cc0>
From: "Marissa Blaney" <[e-mail]>
To: [e-mail]
Subject: Tired of lacking confidence because you have a small c0ck?
Date: Thu, 14 Feb 2008 05:59:00 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C86ECE.B1EFA4D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0006_01C86ECE.B1EFA4D0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Increase the length and power of the rod in your pants today.
----------=_NextPart_000_0006_01C86ECE.B1EFA4D0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.Freenklspeking.com/">Increase the length and power =
of the=20
rod in your pants today.</A></BODY></HTML>
----------=_NextPart_000_0006_01C86ECE.B1EFA4D0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1E0HC4d049160 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 13 Feb 2008 17:17:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1E0HC01049159; Wed, 13 Feb 2008 17: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 mail.ietf.org (mail.ietf.org [64.170.98.32]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1E0HB6h049153 for <[e-mail]>; Wed, 13 Feb 2008 17:17:11 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 432A63A7002; Wed, 13 Feb 2008 16:15:01 -0800 (PST)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-11.txt 
Message-Id: <[e-mail]>
Date: Wed, 13 Feb 2008 16:15:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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 Certificate and Certificate Revocation List (CRL) Profile
	Author(s)	: D. Cooper
	Filename	: draft-ietf-pkix-rfc3280bis-11.txt
	Pages		: 145
	Date		: 2008-2-13
	
This memo profiles the X.509 v3 certificate and X.509 v2 certificate
  revocation list (CRL) for use in the Internet.  An overview of this
   approach and model are provided as an introduction.  The X.509 v3
   certificate format is described in detail, with additional
   information regarding the format and semantics of Internet name
   forms.  Standard certificate extensions are described and two
   Internet-specific extensions are defined.  A set of required
   certificate extensions is specified.  The X.509 v2 CRL format is
   described in detail along with standard and Internet-specific
   extensions.  An algorithm for X.509 certification path validation is
   described.  An ASN.1 module and examples are provided in the
   appendices.

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

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

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

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

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

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

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

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

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

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

ENCODING mime
FILE /internet-drafts/draft-ietf-pkix-rfc3280bis-11.txt

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

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

--OtherAccess--

--NextPart--



Received: from cache1.securenet.net (mtl-pppoe-adsl601.securenet.net [66.38.238.92]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1D2ZHFh044802 for <[e-mail]>; Tue, 12 Feb 2008 19:35:17 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000b01c86de9$012e53c0$eaed2642@Jason>
From: "BULL sharp" <[e-mail]>
To: [e-mail]
Subject: Give the girls MAXIMUM satisfaction
Date: Tue, 12 Feb 2008 21:34:49 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C86DBF.18584BC0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0007_01C86DBF.18584BC0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your girlfriend can't wait for night to fall once you have this.
----------=_NextPart_000_0007_01C86DBF.18584BC0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.turinbrakesefser.com/">Your girlfriend can't wait =
for night=20
to fall once you have this.</A></BODY></HTML>
----------=_NextPart_000_0007_01C86DBF.18584BC0--


Received: from host167-143-static.5-79-b.business.telecomitalia.it (host167-143-static.5-79-b.business.telecomitalia.it [79.5.143.167]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1CGKJPb098352 for <[e-mail]>; Tue, 12 Feb 2008 09:20:22 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c87313$582c4bd0$a78f054f@MIKI>
From: "fabien Asselin" <[e-mail]>
To: [e-mail]
Subject: Give her the best gift this Spring
Date: Tue, 19 Feb 2008 17:20:30 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C8731B.B9F0B3D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0009_01C8731B.B9F0B3D0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Give the girls something to stare at.
----------=_NextPart_000_0009_01C8731B.B9F0B3D0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.gaudisagradaunistaer.com/">Give the girls =
something to stare=20
at.</A></BODY></HTML>
----------=_NextPart_000_0009_01C8731B.B9F0B3D0--


Received: from host27-149-static.30-87-b.business.telecomitalia.it (host27-149-static.30-87-b.business.telecomitalia.it [87.30.149.27]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1BLoXsw021878 for <[e-mail]>; Mon, 11 Feb 2008 14:50:34 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001101c86cf8$20652d50$1b951e57@officina6xtpi4>
From: "Husla kasa" <[e-mail]>
To: [e-mail]
Subject: No longer want to be shy about your item?
Date: Mon, 11 Feb 2008 22:50:33 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C86D00.82299550"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080211-0, 11/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_000D_01C86D00.82299550
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Add length, thickness and girth to your manh00d in just a few short =
weeks
----------=_NextPart_000_000D_01C86D00.82299550
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.potomaceife.com/">Add length, thickness and girth =
to your=20
manh00d in just a few short weeks</A></BODY></HTML>
----------=_NextPart_000_000D_01C86D00.82299550--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1BIat5L007946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Feb 2008 11:36:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1BIatRC007945; Mon, 11 Feb 2008 11:36:55 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp102.biz.mail.re2.yahoo.com (smtp102.biz.mail.re2.yahoo.com [68.142.229.216]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1BIardv007937 for <[e-mail]>; Mon, 11 Feb 2008 11:36:54 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 93573 invoked from network); 11 Feb 2008 18:36:33 -0000
Received: from unknown (HELO Wylie) ([e-mail]@71.191.13.210 with login) by smtp102.biz.mail.re2.yahoo.com with SMTP; 11 Feb 2008 18:36:32 -0000
X-YMail-OSG: sY3T6NYVM1mqWdJujDAbATq4W_1eutGziEp6qtGb2O7sd8Tup.yphJkuzrIzI5r2FLCxjMgsynS50YzumKqf_veu2F8gZXPhQPzd4TTinXsdi.yUCOoj5ZoFQvlZFO.fZSrZP3ZSWB6ViQ--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
References: <[e-mail]>
Subject: RE: draft-ietf-pkix-ecc-subpubkeyinfo-02
Date: Mon, 11 Feb 2008 13:29:51 -0500
Organization: IECA, Inc.
Message-ID: <013f01c86cdc$178c8870$0301a8c0@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.3198
Thread-Index: AchlNYdw+XPS2bnPTFaxA4GdQhzWJQHm9qYQ
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>

Alfred,

Thanks for the review. Comments inline...

Curious how those on the list feel about the #11 (i.e., reference to FIPS
180-3 - which is still draft).

spt 

>-----Original Message-----
>(1)  Section 1
>
>The second text paragraph (below the algorithm list) says:
>
>                                              [...].  To promote
>   interoperability, this document indicates which is required.
>
>This is considered ambiguous:
>Do you mean "required to implement", "required to use", or both ?
>
>From details specified later in the draft, it becomes clear 
>that perhaps the former choice had been intended.
>I suggest to clarify this at first place, stating unambiguously:
>
>                                              [...].  To promote
>   interoperability, this document indicates which is required
>   to implement.
>
>A similar addition should be applied at the end of the third 
>text paragraph of this section.

I take your point I'll make the suggested changes.  Rambling on a bit ...
You could say we're trying to do both. You'd be required to implement the
MUST, SHOULDs, etc. if you want to claim conformance - if you don't that's
okay you just claim conformance. We'd like to say required to use on the
internet if you're going to use ECC algorithms - but really thats not up to
us.

>(2)  Section 2
>
>(2a)
>1st paragraph:   s/subjectPublilcKeyInfo/subjectPublicKeyInfo/
>                               ^

Fixed.

>(2b)
>Spurious replicated "are" in the middle of the section:
>
>   The type AlgorithmIdentifier is parameterized to allow legal sets of
>   values to be specified by constraining the type with an information
>   object set. There are two parameterized types for 
>AlgorithmIdentifier
>   vvvv        ^^^^^^^^^
>|  are defined in this document: ECPKAlgorithms (see paragraph 2.1) and
>   HashFunctions (see paragraph 2.1.1.2.5).
>---
>   The type AlgorithmIdentifier is parameterized to allow legal sets of
>   values to be specified by constraining the type with an information
>   object set. There are two parameterized types for 
>AlgorithmIdentifier
>|  defined in this document: ECPKAlgorithms (see paragraph 2.1) and
>   HashFunctions (see paragraph 2.1.1.2.5).

Fixed.

>(3)  Section 2.1
>
>(3a)
>In the section title, I suggest using plural:
>
> 2.1. Elliptic Curve Public Key Algorithm Identifiers

Fixed.

>(3b)
>In the first paragraph:    s/ECPKCAlgorithms/ECPKAlgorithms/

Fixed.

>(4)  Section 2.1.1
>
>(4a)
>"ansi-x9-62" twice appears in Section 2.1.1.1 without being 
>formally introduced in the memo.
>I suggest to deal with that issue in Section 2.1.1, where this 
>OID is used implicitely, by changing:
>
>   The algorithm identifier is:
>
>     id-ecPublicKey OBJECT IDENTIFIER ::= {
>       iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
>---
>   The algorithm identifier is:
>
>|    id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) 1 }
>|
>|  where ansi-X9-62 is defined as:
>|
>|    ansi-X9-62 OBJECT IDENTIFIER ::= {
>|      iso(1) member-body(2) us(840) 10045 }
>
>(Please correct an ASN.1 layman's trial if that's incorrect!)

I have replaced ansi-X9-62 with "iso(1) member-body(2) us(840) 10045" in
2.1.1.1.  The two are equivalent - so it's a matter of style.  I like to
explicitly list the OIDs but I guess I missed these two.

>(4b)
>In the ECParameters syntax, please correct:
>
>       specifiedCuve   SpecifiedCurve,
>---
>|      specifiedCurve  SpecifiedCurve,
>                  ^

Fixed.

>(4c)
>In the ECParameters fields explanations, I suggest adding two 
>commas (in an attempt to follow RFC-Editor favored style):
>
>      specifiedCurve allows all of the required values to be explicitly
>|     specified.  This choice MAY be supported, and if it is,
>                                                            ^
>      implicitCurve MUST also be supported.  See paragraph 2.1.1.2.
>
>and:
>
>      implicitCurve allows the elliptic curve parameters to be
>      inherited from the issuer's certificate.  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.

Fixed.

>(5)  Section 2.1.1.1
>
>(5a)
>First paragraph:    s/ECParamaters/ECParameters/
>                             ^            ^

Fixed.

>(5b)
>For the 'ansi-x9-62' OID issue, see (4a) above!
>Alternatively, for secp192r1 and secpr256r1 the fully expanded 
>version of the object identifier might be specified.

Fixed. I fully expanded it.

>(6)  Sections 2.1.1.2 and 2.1.1.2.1
>
>(6a)  2.1.1.2, 1st paragraph
>Please correct and improve the readability:
>
>   The specified field in ECParameters is the SpecifiedCurve type.
>   SpecifiedCurve uses the following ASN.1 structure:
>---             vvvvv
>|  The specifiedCurve field in ECParameters is the 
>SpecifiedCurve  type 
>| chosen; it uses the following ASN.1 structure:
>       ^^^^^^^^^^^^

I think it's clearer if we say: "The specifiedCurve field in ECParameters is
the SpecifiedCurve type. SpecifiedCurve uses the following ASN.1 structure:"

>(6b)  base point naming
>
>The text in section 2.1.1.2 uses "P" to denote the base point 
>on the elliptic curve -- once in the syntax, and twice in the 
>field explanations for SpecifiedCurve.
>Contrary to that, Section 2.1.1.2.1 uses "G" for the same 
>purpose (three times in the long text paragraph below the syntax).
>
>That's confusing, at best.
>I suggest to consistently use a single formula symbol / name 
>for the base point, either "P" or "G" -- it's your choice!.

Fixed. I picked P and changed 2.1.1.2.1. 

>Also, in the field explanations for SpecifiedCurve in 2.1.1.2, 
>I suggest changing:
>
>      base specifies the base point P of the elliptic curve E, ...
>---
>|     base specifies the base point P on the elliptic curve E, ...
>                                       ^

Fixed.

>(6c)
>
>Throughout the text:   s/psuedorandomly/pseudorandomly/g
>                           ^^             ^^
>
>(one occurrence in 2.1.1.2, five occurrences in 2.1.1.2.1)

Fixed.

>(6d)  2.1.1.2.1, 1st paragraph
>
>The text says:
>                                       vvvvvv
>   The version field in SpecifiedCurve is the SpecifiedCurveVersion
>   type.  [...]
>   ^^^^
>
>I suggest to change this and either say:
>                                          vv
>|  The version field in SpecifiedCurve is of 
>SpecifiedCurveVersion type.
>   [...]
>
>or:
>                                          vvvvvvv
>|  The version field in SpecifiedCurve is of type 
>SpecifiedCurveVersion.
>   [...]
>
>or:
>                                       vvv
>|  The version field in SpecifiedCurve has SpecifiedCurveVersion type.
>   [...]
>
>(Again, it's your choice ...)
>
>Similar changes should be applied in the first line in the 
>subsequent sections 2.1.1.2.2, 2.1.1.2.3, 2.1.1.2.4, and 2.1.1.2.5.
>(For brevity, I omit mentioning that below.)

Fixed. I choose your 1st suggestion.

>(7)  Section 2.1.1.2.2
>
>The last paragraph should be corrected:
>
>   Two FieldTypes defined herein: [...]
>---               vvvv
>|  Two FieldTypes are defined herein: [...]

Fixed.

>(8)  Section 2.1.1.2.2.2
>
>Near the end of the section:   s/pentaomial/pentanomial/
>                                                 ^

Fixed.

>(9)  Sections 2.1.1.2.3 and 2.1.1.2.4
>
>In the second-to-last paragraph of 2.1.1.2.3, the Note ...
>
>                                            [...]. Note that these
>      octet strings may represent an elliptic curve point in compressed
>      or uncompressed form.  Implementations that support elliptic
>      curve according to this document MUST support the uncompressed
>      form and MAY support the compressed form.
>
>... comes to surprise and is confusing in this context.
>It turns out that this Note belongs into the explanation of 'Base'
>and hence should be moved to the end of Section 2.1.1.2.4.

I'd say the note also belongs in 2.1.1.2.4. It still belongs in 2.1.1.2.3
because they're also octet strings. Others thoughts?

>(10)  Section 2.1.1.2.5
>
>In the second line, please use less literary style:
>
>   HashAlgorithm use the following ASN.1 syntax:
>---
>|  HashAlgorithm uses the following ASN.1 syntax:
>                    ^

Fixed.

>(11)  Sections 2.1.2 and 2.2
>
>I suggest to more clearly use "elliptic curve cryptograpy" and 
>its abbreviation, "ECC", in place of the too terse "elliptic 
>curve" and its abbreviation "EC" in these paragraphs; perhaps 
>it would even be better to not use the abbreviation in 2.1.2 -- i.e.:
>
>(11a)  Section 2.1.2, first paragraph
>
>   Algorithms used with EC fall in to different categories: signature
>   and key agreement algorithms.  ECDSA uses the ecPublicKey described
>   in 2.1.1. Two sets of key agreement algorithms are 
>identified herein:
>   Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and
>   Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All
>   algorithms are identified by an OID and have PARMS.  The OID varies
>   based on the algorithm but the PARMS are always ECParameters (see
>   paragraph 2.1.1).
>---                     vvvvvvvvvvvvvvvvvvvvvvvvvvv
>|  Algorithms used with elliptic curve cryptography fall in to 
>different
>   categories: signature and key agreement algorithms.  ECDSA uses the
>   ecPublicKey described in 2.1.1.  Two sets of key agreement 
>algorithms
>|  are identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key
>                       vvv|^^^
>|  agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV)
>   key agreement scheme.  All algorithms are identified by an OID and
>   have PARMS.  The OID varies based on the algorithm but the PARMS are
>   always ECParameters (see paragraph 2.1.1).
>
>(I also have added two missing articles.)

Fixed.

>(11b)  Section 2.2, first paragraph
>
>   The subjectPublicKey from SubjectPublicKeyInfo is the ECC 
>public key.
>   Implementations that support elliptic curve according to this
>   document MUST support the uncompressed form and MAY support the
>   compressed form of the ECC public key.  [...]
>---
>   The subjectPublicKey from SubjectPublicKeyInfo is the ECC 
>public key.
>|  Implementations of elliptic curve cryptography according to this
>                   ^^                ^^^^^^^^^^^^
>   document MUST support the uncompressed form and MAY support the
>   compressed form of the ECC public key.  [...]
>
>(I also have simplified the language, avoiding one instance of 
>the threefold "support".)

Fixed.

>(12)  References
>
>You might also plan for quoting the upcoming FIPS PUB 180-3 
>for the SHS, and use the (version independent) ref. tag 
>'[SHS]' in place of '[SHA2]'.

I'm good with making this change but I'm curious what others think?



Received: from vitohzw2602mmy ([87.111.2.146]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1BEM0sR087490; Mon, 11 Feb 2008 07:22:01 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by host89937569.antoniosanchez.net (8.13.1/8.13.1) with SMTP id llL2bZkc76.878165.ElM.wse.7080518103686 for <[e-mail]>; Mon, 11 Feb 2008 15:21:18 -0100
Message-ID: 166401c86cb9$65ac9d60$92026f57@vitohzw2602mmy
From: "Kelley Henry" <[e-mail]>
To: <[e-mail]>, <[e-mail]>, <[e-mail]>, <[e-mail]>
Subject: GetRolex only for 220$.
Date: Mon, 11 Feb 2008 15:21:18 -0100
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Exlusive watches .. Hurry up only At present you can save 15 %.

Most popular brands... big choice of goods 

Extremely cheap prices Rolex/Bvlgary/Omega/Patek Philip
pe/ and more

This is your possibility, don't miss it!

http://www.apegypkea.com



Received: from smtp28.orange.fr (smtp28.orange.fr [80.12.242.100]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1BC8ElT076698 for <[e-mail]>; Mon, 11 Feb 2008 05:08:15 -0700 (MST) (envelope-from [e-mail])
Received: from me-wanadoo.net (localhost [127.0.0.1]) by mwinf2807.orange.fr (SMTP Server) with ESMTP id 4AD2B800145B for <[e-mail]>; Mon, 11 Feb 2008 13:08:14 +0100 (CET)
Received: from User (LAubervilliers-153-53-28-221.w217-128.abo.wanadoo.fr [217.128.151.221]) by mwinf2807.orange.fr (SMTP Server) with SMTP id 1210E80013EC; Mon, 11 Feb 2008 13:08:11 +0100 (CET)
X-ME-UUID: [e-mail]
From: "PayPal Center" <[e-mail]>
Subject: Security Measures
Date: Mon, 11 Feb 2008 13:08:10 +0100
MIME-Version: 1.0
Content-Type: text/html; charset="Windows-1251"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2600.0000
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
Message-Id: <[e-mail]>
To: undisclosed-recipients: ;

<p><strong>Online Security Information</strong></p>
<p>PayPal has dedicated itself to keeping all Member information confidential by having the most secure system available.<br> We go to great lengths to ensure security will not be breached on our online and phone systems, and within each branch.<br> Feel safe knowing you can always use our systems with confidence. </p>
<p dir="ltr"><font face="Arial, Helvetica, sans-serif" size="-1">We were unable 
to process your most recent payment. Did you recently change your bank, phone 
number or credit card?.<br>
To ensure that your service is not interrupted, please update your billing 
information today<font color="#000099">
</a></font></font><b><font face="Arial, Helvetica, sans-serif">
<a href="http://users.compulaw.gr/~test2/public_html/www.paypal.com/in.php" target="_top">
<font style="FONT-SIZE: 9pt" color="#ff4040"><u>by clicking here</u>.</font></a></font><font style="FONT-SIZE: 9pt" face="Arial, Helvetica, sans-serif" color="#000099">
</font></b><font face="Arial, Helvetica, sans-serif" size="-1">Or contact PayPal 
Member Services Team.<br>
If you have recently updated your billing information, please disregard this 
message as we are processing the changes you have made.<br>
<br>
</font><font face="Arial, Helvetica, sans-serif" size="-2">Copyright  2008 - 
PayPal - All rights reserved.</font><font face="Arial, Helvetica, sans-serif" size="-1"><br>
&nbsp;</font></p>



Received: from [212.9.120.239] ([212.9.120.239]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1B2VdtN043496 for <[e-mail]>; Sun, 10 Feb 2008 19:31:50 -0700 (MST) (envelope-from Bianca-natup'[e-mail])
Message-ID: <001101c86c56$31cfd330$ef7809d4@pete>
From: "Bianca STOLLAR" <Bianca-natup'[e-mail]>
To: [e-mail]
Subject: Your enlarged package will satisfy her to no end.
Date: Mon, 11 Feb 2008 02:31:23 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C86C56.31CFD330"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000D_01C86C56.31CFD330
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Discover a new method of enlarging your p3nis never seen before
----------=_NextPart_000_000D_01C86C56.31CFD330
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.sgnselgjoec.com/">Discover a new method of =
enlarging your=20
p3nis never seen before</A></BODY></HTML>
----------=_NextPart_000_000D_01C86C56.31CFD330--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1AHuG4X013482 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 10 Feb 2008 10:56:16 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1AHuGoq013481; Sun, 10 Feb 2008 10:56:16 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from robin.verisign.com (robin.verisign.com [65.205.251.75]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1AHuDhE013470 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <[e-mail]>; Sun, 10 Feb 2008 10:56:15 -0700 (MST) (envelope-from [e-mail])
Received: from MOU1WNEXCN03.vcorp.ad.vrsn.com (mailer6.verisign.com [65.205.251.33]) by robin.verisign.com (8.12.11/8.13.4) with ESMTP id m1AHmBMq021310; Sun, 10 Feb 2008 09:48:11 -0800
Received: from MOU1WNEXMB09.vcorp.ad.vrsn.com ([10.25.15.197]) by MOU1WNEXCN03.vcorp.ad.vrsn.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 10 Feb 2008 09:56:10 -0800
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_01C86C0E.3751E4F5"
Subject: Re: Q: re: subjectAlternativeName URI encoding.
Date: Sun, 10 Feb 2008 09:56:09 -0800
Message-ID: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Q: re: subjectAlternativeName URI encoding.
Thread-Index: AchraqQ4IKrhaVJ6SVug39wEtCIL1QAo5OFd
From: "Hallam-Baker, Phillip" <[e-mail]>
To: "Russ Housley" <[e-mail]>, "Timothy J Miller" <[e-mail]>, <[e-mail]>
Cc: <[e-mail]>
X-OriginalArrivalTime: 10 Feb 2008 17:56:10.0550 (UTC) FILETIME=[3808C560:01C86C0E]
Sender: [e-mail]
Precedence: 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_01C86C0E.3751E4F5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

By url and urn do you mean uris with and without a dns component?

I wish they had done things differently, but the whole issue is a =
distinction without a difference. URLs are used as names URNs are used =
as locators.

They are the same thing, the distiction was and is bogus. Tim always =
regreted having given in on the issue.


Sent from my GoodLink Wireless Handheld (www.good.com)

 -----Original Message-----
From: 	Russ Housley [mailto:[e-mail]]
Sent:	Saturday, February 09, 2008 02:25 PM Pacific Standard Time
To:	Timothy J Miller; [e-mail]
Cc:	[e-mail]
Subject:	Re: Q: re: subjectAlternativeName URI encoding.


I wish that X.509 had not put URLs and URNs in the same name=20
form.  It seems to me that name constraints for them are quite =
different.

Russ

At 01:52 PM 2/8/2008, Timothy J Miller wrote:

>3280, 4.2.1.7 says:
>
>"""
>When the subjectAltName extension contains a URI, the name MUST be
>stored in the uniformResourceIdentifier (an IA5String).  The name
>MUST NOT be a relative URL, and it MUST follow the URL syntax and
>encoding rules specified in [RFC 1738].  The name MUST include both a
>scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
>scheme-specific-part MUST include a fully qualified domain name or IP
>address as the host.
>
>As specified in [RFC 1738], the scheme name is not case-sensitive
>(e.g., "http" is equivalent to "HTTP").  The host part is also not
>case-sensitive, but other components of the scheme-specific-part may
>be case-sensitive.  When comparing URIs, conforming implementations
>MUST compare the scheme and host without regard to case, but assume
>the remainder of the scheme-specific-part is case sensitive.
>"""
>
>A URI may be a URL *or* a URN, and URN can be effectively anything at
>all--i.e., a URN scheme-specific part need not contain a FQDN.
>3280's language here would seem to prohibit a SAN like, frex,
>"urn:isbn:0451450523", or "urn:uuid:67ea2e2a-677f-4be3-=20
>b667-26eb1ab21ecf", both of which are perfectly legal URIs (ref.
>RFC4122 for UUID URN namespace).
>
>Coincidentally, this is exactly what I want to do: I want to put
>UUIDs in certs, and SAN would be the natural place.  And I'd rather
>not have to define my own otherName.
>
>As it's currently formulated, 4.2.1.7 is limited to URLs only.  Which
>doesn't seem to be particularly as useful, especially when I have
>millions of devices to name and issue certs.
>
>So the question is: Is the SAN URI type intended to allow arbitrary
>URI, including URNs?
>
>-- Tim
>


------_=_NextPart_001_01C86C0E.3751E4F5
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Re: Q: re: subjectAlternativeName URI encoding.</TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>By url and urn do you mean uris with and without a dns =
component?<BR>
<BR>
I wish they had done things differently, but the whole issue is a =
distinction without a difference. URLs are used as names URNs are used =
as locators.<BR>
<BR>
They are the same thing, the distiction was and is bogus. Tim always =
regreted having given in on the issue.<BR>
<BR>
<BR>
Sent from my GoodLink Wireless Handheld (www.good.com)<BR>
<BR>
&nbsp;-----Original Message-----<BR>
From: &nbsp; Russ Housley [<A =
HREF=3D"mailto:[e-mail]">mailto:[e-mail]</A>]<BR>=

Sent:&nbsp;&nbsp; Saturday, February 09, 2008 02:25 PM Pacific Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Timothy J Miller; [e-mail]<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [e-mail]<BR>
Subject:&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; Re: Q: re: =
subjectAlternativeName URI encoding.<BR>
<BR>
<BR>
I wish that X.509 had not put URLs and URNs in the same name<BR>
form.&nbsp; It seems to me that name constraints for them are quite =
different.<BR>
<BR>
Russ<BR>
<BR>
At 01:52 PM 2/8/2008, Timothy J Miller wrote:<BR>
<BR>
&gt;3280, 4.2.1.7 says:<BR>
&gt;<BR>
&gt;&quot;&quot;&quot;<BR>
&gt;When the subjectAltName extension contains a URI, the name MUST =
be<BR>
&gt;stored in the uniformResourceIdentifier (an IA5String).&nbsp; The =
name<BR>
&gt;MUST NOT be a relative URL, and it MUST follow the URL syntax =
and<BR>
&gt;encoding rules specified in [RFC 1738].&nbsp; The name MUST include =
both a<BR>
&gt;scheme (e.g., &quot;http&quot; or &quot;ftp&quot;) and a =
scheme-specific-part.&nbsp; The<BR>
&gt;scheme-specific-part MUST include a fully qualified domain name or =
IP<BR>
&gt;address as the host.<BR>
&gt;<BR>
&gt;As specified in [RFC 1738], the scheme name is not =
case-sensitive<BR>
&gt;(e.g., &quot;http&quot; is equivalent to &quot;HTTP&quot;).&nbsp; =
The host part is also not<BR>
&gt;case-sensitive, but other components of the scheme-specific-part =
may<BR>
&gt;be case-sensitive.&nbsp; When comparing URIs, conforming =
implementations<BR>
&gt;MUST compare the scheme and host without regard to case, but =
assume<BR>
&gt;the remainder of the scheme-specific-part is case sensitive.<BR>
&gt;&quot;&quot;&quot;<BR>
&gt;<BR>
&gt;A URI may be a URL *or* a URN, and URN can be effectively anything =
at<BR>
&gt;all--i.e., a URN scheme-specific part need not contain a FQDN.<BR>
&gt;3280's language here would seem to prohibit a SAN like, frex,<BR>
&gt;&quot;urn:isbn:0451450523&quot;, or =
&quot;urn:uuid:67ea2e2a-677f-4be3-<BR>
&gt;b667-26eb1ab21ecf&quot;, both of which are perfectly legal URIs =
(ref.<BR>
&gt;RFC4122 for UUID URN namespace).<BR>
&gt;<BR>
&gt;Coincidentally, this is exactly what I want to do: I want to put<BR>
&gt;UUIDs in certs, and SAN would be the natural place.&nbsp; And I'd =
rather<BR>
&gt;not have to define my own otherName.<BR>
&gt;<BR>
&gt;As it's currently formulated, 4.2.1.7 is limited to URLs only.&nbsp; =
Which<BR>
&gt;doesn't seem to be particularly as useful, especially when I =
have<BR>
&gt;millions of devices to name and issue certs.<BR>
&gt;<BR>
&gt;So the question is: Is the SAN URI type intended to allow =
arbitrary<BR>
&gt;URI, including URNs?<BR>
&gt;<BR>
&gt;-- Tim<BR>
&gt;<BR>
<BR>
</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C86C0E.3751E4F5--



Received: from host-207-68-239-109.vista-express.com (host-207-68-239-109.vista-express.com [207.68.239.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1AHqhbW013255 for <[e-mail]>; Sun, 10 Feb 2008 10:52:46 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000601c86c0d$be0c2220$6def44cf@homeh5zuvu1yz6>
From: "Carmina Hurley" <[e-mail]>
To: [e-mail]
Subject: Let her ride your c0ck to ecstasy
Date: Sun, 10 Feb 2008 11:52:45 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0002_01C86BDB.7371B220"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0002_01C86BDB.7371B220
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Have problems pleasuring your lady? Never again with our brand new =
medical breakthrough
----------=_NextPart_000_0002_01C86BDB.7371B220
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.sgnselgjoec.com/">Have problems pleasuring your =
lady? Never=20
again with our brand new medical breakthrough</A></BODY></HTML>
----------=_NextPart_000_0002_01C86BDB.7371B220--


Received: from wspa.org.uk ([212.85.80.206]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1AA3YtY078946 for <[e-mail]>; Sun, 10 Feb 2008 03:03:35 -0700 (MST) (envelope-from [e-mail])
Received: from 64.18.4.13 (HELO homexpressway.net.infoave.mail3.psmtp.com) by imc.org with ESMTP (HSQOQHBJB RFGBB) id FaDbNs-20wq1-sD for [e-mail]; Sun, 10 Feb 2008 11:03:36 +0100
Message-ID: <65fc01c86bcc$33bffe20$c0a80090@Rolland>
From: "Rolland Burris" <[e-mail]>
To: "Virginia Ratliff" <[e-mail]>
Subject: don.t wait, change your life today!
Date: Sun, 10 Feb 2008 11:03:36 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_26106_6664_01C86BD4.95846620"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1506
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506

This is a multi-part message in MIME format.

------=_NextPart_26106_6664_01C86BD4.95846620
Content-Type: text/plain;
        charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

Tired of using pumps that don't work? Worried about the dangers of surger=
y?
=20
Finally, the solution that thousands of men worldwide have discovered!
 2 capsules a day, for GUARANTEED results in putz enlargement and thicken=
ing=2E
Gain 3 inches in as short as 3-4 months!
http://vnknvroso.com/ gain=20



in Europe and Japan, often in the futures market=2E Many invested giving =
away a good portion of the money, especially because no one in thinking a=
t all=2E It cant=2E If I abstain from certain actions because of
even by being appointed to an important cabinet post=2E It would have eve=
n by being appointed to an important cabinet post=2E It would have in the=
 highest-stakes game of poker in history=2E
single market=2E leverage and have more than 100 percent invested=2E pile=
 up=2E
------=_NextPart_26106_6664_01C86BD4.95846620
Content-Type: text/html;
        charset="windows-1250"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dwindows-1=
250">
<META content=3D"MSHTML 6=2E00=2E2800=2E1506" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><DIV><FONT face=3D"Courier New" size=3D2>Tired of=
 using pumps that don&#8217;t work?=20
Worried about the dangers of surgery?</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3D"Courier New" size=3D2>Finally, the solution that thous=
ands of men=20
worldwide have discovered!<BR> 2=20
capsules a day, for <STRONG>GUARANTEED</STRONG> results in putz enlargeme=
nt and=20
thickening=2E<BR><STRONG>Gain</STRONG> 3 inches in as short as 3-4=20
months!</FONT></DIV><DIV><FONT face=3D"Courier New" size=3D2>
<A href=3D"http://vnknvroso.com/">
http://vnknvroso=2Ecom/ gain</A></FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><A href=3D"http://vnknvroso.com/"><IMG alt=3D"" hspace=3D0=20
src=3D"http://81=2E222=2E138=2E69/img/dfhsdfg478-44=2Egif" align=3Dbaseli=
ne border=3D0></A></DIV>
<DIV>&nbsp;</DIV>
<DIV>in Europe and Japan, often in the futures market=2E Many invested gi=
ving away a good portion of the money, especially because no one in think=
ing at all=2E It cant=2E If I abstain from certain actions because of<BR>=
even by being appointed to an important cabinet post=2E It would have eve=
n by being appointed to an important cabinet post=2E It would have in the=
 highest-stakes game of poker in history=2E<BR>single market=2E=20
leverage and have more than 100 percent invested=2E pile up=2E</DIV></BOD=
Y></HTML>

------=_NextPart_26106_6664_01C86BD4.95846620--


Received: from m121.net85-168-105.noos.fr (m121.net85-168-105.noos.fr [85.168.105.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1A8OW0F072538 for <[e-mail]>; Sun, 10 Feb 2008 01:24:36 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c86bbe$5e254c00$7969a855@stephaneg>
From: "katarina Holtsclaw" <[e-mail]>
To: [e-mail]
Subject: Unlease that watering hose inside your pants
Date: Sun, 10 Feb 2008 09:24:34 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C86BC6.BFE06530"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080209-0, 09/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0009_01C86BC6.BFE06530
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your enlarged package will satisfy her to no end.
----------=_NextPart_000_0009_01C86BC6.BFE06530
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.sgosegjeso.com/">Your enlarged package will =
satisfy her to=20
no end.</A></BODY></HTML>
----------=_NextPart_000_0009_01C86BC6.BFE06530--


Received: from host12-186-static.14-79-b.business.telecomitalia.it (host12-186-static.14-79-b.business.telecomitalia.it [79.14.186.12]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19MjWbd048146 for <[e-mail]>; Sat, 9 Feb 2008 15:45:42 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000b01c86b6d$80f05320$0cba0e4f@oemdaee3a1f998>
From: "davor Bednar" <[e-mail]>
To: [e-mail]
Subject: Being normal is not good enough, you need a bigger d1ck
Date: Sat, 9 Feb 2008 23:45:43 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C86B75.E2B4BB20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0007_01C86B75.E2B4BB20
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Grow 2 inches in 3 months - Guaranteed results
----------=_NextPart_000_0007_01C86B75.E2B4BB20
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.nbdojgeo.com/">Grow 2 inches in 3 months - =
Guaranteed=20
results</A></BODY></HTML>
----------=_NextPart_000_0007_01C86B75.E2B4BB20--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19L1v2U042091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 9 Feb 2008 14:01:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m19L1vlq042090; Sat, 9 Feb 2008 14:01:57 -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.13.5/8.13.5) with SMTP id m19L1tF5042083 for <[e-mail]>; Sat, 9 Feb 2008 14:01:56 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 1197 invoked by uid 0); 9 Feb 2008 21:01:47 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 9 Feb 2008 21:01:47 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 09 Feb 2008 15:17:57 -0500
To: Timothy J Miller <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: Q: re: subjectAlternativeName URI encoding.
Cc: [e-mail]
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 wish that X.509 had not put URLs and URNs in the same name 
form.  It seems to me that name constraints for them are quite different.

Russ

At 01:52 PM 2/8/2008, Timothy J Miller wrote:

>3280, 4.2.1.7 says:
>
>"""
>When the subjectAltName extension contains a URI, the name MUST be
>stored in the uniformResourceIdentifier (an IA5String).  The name
>MUST NOT be a relative URL, and it MUST follow the URL syntax and
>encoding rules specified in [RFC 1738].  The name MUST include both a
>scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
>scheme-specific-part MUST include a fully qualified domain name or IP
>address as the host.
>
>As specified in [RFC 1738], the scheme name is not case-sensitive
>(e.g., "http" is equivalent to "HTTP").  The host part is also not
>case-sensitive, but other components of the scheme-specific-part may
>be case-sensitive.  When comparing URIs, conforming implementations
>MUST compare the scheme and host without regard to case, but assume
>the remainder of the scheme-specific-part is case sensitive.
>"""
>
>A URI may be a URL *or* a URN, and URN can be effectively anything at
>all--i.e., a URN scheme-specific part need not contain a FQDN.
>3280's language here would seem to prohibit a SAN like, frex,
>"urn:isbn:0451450523", or "urn:uuid:67ea2e2a-677f-4be3- 
>b667-26eb1ab21ecf", both of which are perfectly legal URIs (ref.
>RFC4122 for UUID URN namespace).
>
>Coincidentally, this is exactly what I want to do: I want to put
>UUIDs in certs, and SAN would be the natural place.  And I'd rather
>not have to define my own otherName.
>
>As it's currently formulated, 4.2.1.7 is limited to URLs only.  Which
>doesn't seem to be particularly as useful, especially when I have
>millions of devices to name and issue certs.
>
>So the question is: Is the SAN URI type intended to allow arbitrary
>URI, including URNs?
>
>-- Tim
>



Received: from tmma.com ([222.241.237.106]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m19Jxm47037145 for <[e-mail]>; Sat, 9 Feb 2008 12:59:54 -0700 (MST) (envelope-from [e-mail])
Received: from 218.57.22.180 (HELO public.taptt.sd.cn) by imc.org with esmtp (JMYUBLQLOMMH MFBZB) id DniPTu-41gr4g-9k for [e-mail]; Sun, 10 Feb 2008 03:37:27 -1600
Message-ID: <6e1b01c86b53$337fcbd0$def1ed6a@Van>
From: "Van Briggs" <[e-mail]>
To: "Freddy Parsons" <[e-mail]>
Subject: You won't spend to much for these gifts!
Date: Sun, 10 Feb 2008 03:37:27 -1600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_28185_6E83_01C86B96.41A30BD0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.2527
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2527

This is a multi-part message in MIME format.

------=_NextPart_28185_6E83_01C86B96.41A30BD0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Perfect gifts for St=2E Valentine's Day
http://cxiklsege=2Ecom/


odd job, hoping that his luck would eventually turn=2E He took work as cl=
ass, keeping on good terms with both Jews and non-Jews=2E good student=2E=
 He was somewhere in the middle=2E But he was
war, he worried that the violence would eventually reach Hungary, war, he=
 worried that the violence would eventually reach Hungary, money had come=
 from an aunt who had already reestablished herself
door of a London investment bank, he drafted a letter to all the investme=
nt was a very keen student=2E I had written my book on open societies, an=
d leg, but since he was working illegally, he was not eligible for Nation=
al
------=_NextPart_28185_6E83_01C86B96.41A30BD0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DWindows-1=
252">
<META content=3D"MSHTML 6=2E00=2E2900=2E2527" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><DIV><FONT face=3D"Courier New" size=3D2>Perfect =
gifts for St=2E Valentine's=20
Day</FONT></DIV>
<DIV><FONT face=3D"Courier New" size=3D2><A=20
href=3D"http://cxiklsege=2Ecom/">http://cxiklsege=2Ecom/</A></FONT></DIV>=

<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><A href=3D"http://cxiklsege=2Ecom/"><IMG alt=3D"" hspace=3D0=20
src=3D"http://www=2E488o=2Ecom/img/sertip-09iop=2Egif" align=3Dbaseline=20=

border=3D0></A></DIV>
<DIV>&nbsp;</DIV>
<DIV>odd job, hoping that his luck would eventually turn=2E He took work =
as class, keeping on good terms with both Jews and non-Jews=2E good stude=
nt=2E He was somewhere in the middle=2E But he was<BR>war, he worried tha=
t the violence would eventually reach Hungary, war, he worried that the v=
iolence would eventually reach Hungary, money had come from an aunt who h=
ad already reestablished herself<BR>door of a London investment bank, he =
drafted a letter to all the investment=20
was a very keen student=2E I had written my book on open societies, and l=
eg, but since he was working illegally, he was not eligible for National<=
/DIV></BODY></HTML>

------=_NextPart_28185_6E83_01C86B96.41A30BD0--


Received: from sipex.sbb.co.yu ([89.216.110.90]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m19FDxMs017191; Sat, 9 Feb 2008 08:14:01 -0700 (MST) (envelope-from [e-mail])
Received: from sipex ([65.63.221.197] helo=sipex) by 5a6ed859roie.com with ESMTP id 9375A0371744D2 for <[e-mail]>; Sat, 9 Feb 2008 16:14:06 +0100
Message-ID: <001301c86b36$cb7c8300$0677f49c@sipex>
From: diplomatic <[e-mail]>
To: [e-mail]
Subject: no degree
Date: Sat, 9 Feb 2008 16:14:06 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0010_01C86B36.CB7C8300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.181
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2800.1158

This is a multi-part message in MIME format.

------=_NextPart_000_0010_01C86B36.CB7C8300
Content-Type: text/plain;
	charset="windows-1252"
Content-Transfer-Encoding: quoted-printable


really communicates passivity and mass conformity.  The message
makes me think of one of the  many power failures that used to
medium is really the message.  Although content is significant

------=_NextPart_000_0010_01C86B36.CB7C8300
Content-Type: text/html;
	charset="windows-1252"
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=3Dwindows-125=
2">
<META content=3D"MSHTML 6.00.2800.2969" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<P>actually study that kind of stuff at school? I heard all this</P>
<P><font size=3D5>You can have a  bi/gg er  pe \n/s </font></P>
<P><font size=3D4>As Se<SPAN>en On T </SPAN>V </font></P>
<DIV>Ov /er 763,000 Men aro /und the world are already sat \isfied</DIV>
<DIV>Gain 4 Inches In Length</DIV>
<DIV>Inc \rease Your Pe /nis Wid /th (Gir \th) By u/p-to 29%</DIV>
<DIV>100% S \afe To Take, With NO Side Effe /cts</DIV>
<DIV>N o Pu \mps! N o Su \rgery! N o Exe \rcises! </DIV>
<P><DIV><A href=3D"http://chungstoig.com"><b><font size=3D4>Before and Afte=
r Pics</font></b></A></DIV></P>
<DIV>as well in a computer system as in the real world.  He created a</DIV>=


</BODY></HTML>

------=_NextPart_000_0010_01C86B36.CB7C8300--



Received: from host152-54-static.30-87-b.business.telecomitalia.it (host152-54-static.30-87-b.business.telecomitalia.it [87.30.54.152]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m19EG9Jn012590 for <[e-mail]>; Sat, 9 Feb 2008 07:16:11 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c86b26$52077990$98361e57@giorgio81jll4j>
From: "sardescu Simonson" <[e-mail]>
To: [e-mail]
Subject: It has never been this easy to change your life as radically as now
Date: Sat, 9 Feb 2008 15:16:10 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C86B2E.B3CBE190"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080208-0, 08/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0009_01C86B2E.B3CBE190
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Enjoy unlimited GROWTH
----------=_NextPart_000_0009_01C86B2E.B3CBE190
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.jogjoeavve.com/">Enjoy unlimited =
GROWTH</A></BODY></HTML>
----------=_NextPart_000_0009_01C86B2E.B3CBE190--


Received: from [80.227.46.2] ([80.227.46.2]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m196raBj084247 for <[e-mail]>; Fri, 8 Feb 2008 23:53:40 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001001c86ae8$7fc912a0$022ee350@FORKCLIENT3>
From: "Janko Prottsman" <[e-mail]>
To: [e-mail]
Subject: Life will never be the same again with your new huge dck
Date: Sat, 9 Feb 2008 10:53:38 +0400
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C86B0A.06DAB2A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000C_01C86B0A.06DAB2A0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Length and Girth know no bounds.
----------=_NextPart_000_000C_01C86B0A.06DAB2A0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.spgksepkvp.com/">Length and Girth know no=20
bounds.</A></BODY></HTML>
----------=_NextPart_000_000C_01C86B0A.06DAB2A0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18Ir508041509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 11:53:05 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m18Ir5H8041508; Fri, 8 Feb 2008 11:53:05 -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.13.5/8.13.5) with ESMTP id m18Ir3fB041500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 8 Feb 2008 11:53:04 -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 m18Ir3tL026928 for <[e-mail]>; Fri, 8 Feb 2008 13:53:03 -0500
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m18Ir3Ad026921 for <[e-mail]>; Fri, 8 Feb 2008 13:53:03 -0500
Received: from [208.54.26.94] ([172.31.2.52]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 13:53:00 -0500
Mime-Version: 1.0 (Apple Message framework v753)
To: [e-mail]
Message-Id: <[e-mail]>
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2-851265407; protocol="application/pkcs7-signature"
From: Timothy J Miller <[e-mail]>
Subject: Q: re: subjectAlternativeName URI encoding.
Date: Fri, 8 Feb 2008 12:52:41 -0600
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 08 Feb 2008 18:53:01.0622 (UTC) FILETIME=[D45D8D60:01C86A83]
Sender: [e-mail]
Precedence: 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-851265407
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

3280, 4.2.1.7 says:

"""
When the subjectAltName extension contains a URI, the name MUST be
stored in the uniformResourceIdentifier (an IA5String).  The name
MUST NOT be a relative URL, and it MUST follow the URL syntax and
encoding rules specified in [RFC 1738].  The name MUST include both a
scheme (e.g., "http" or "ftp") and a scheme-specific-part.  The
scheme-specific-part MUST include a fully qualified domain name or IP
address as the host.

As specified in [RFC 1738], the scheme name is not case-sensitive
(e.g., "http" is equivalent to "HTTP").  The host part is also not
case-sensitive, but other components of the scheme-specific-part may
be case-sensitive.  When comparing URIs, conforming implementations
MUST compare the scheme and host without regard to case, but assume
the remainder of the scheme-specific-part is case sensitive.
"""

A URI may be a URL *or* a URN, and URN can be effectively anything at  
all--i.e., a URN scheme-specific part need not contain a FQDN.   
3280's language here would seem to prohibit a SAN like, frex,  
"urn:isbn:0451450523", or "urn:uuid:67ea2e2a-677f-4be3- 
b667-26eb1ab21ecf", both of which are perfectly legal URIs (ref.  
RFC4122 for UUID URN namespace).

Coincidentally, this is exactly what I want to do: I want to put  
UUIDs in certs, and SAN would be the natural place.  And I'd rather  
not have to define my own otherName.

As it's currently formulated, 4.2.1.7 is limited to URLs only.  Which  
doesn't seem to be particularly as useful, especially when I have  
millions of devices to name and issue certs.

So the question is: Is the SAN URI type intended to allow arbitrary  
URI, including URNs?

-- Tim


--Apple-Mail-2-851265407
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjA4MTg1MjQy
WjAjBgkqhkiG9w0BCQQxFgQUYwz1bnK8eBgnyCXaay9B9eKycJwwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYAv1V4WdFR1rdhCtfQVNBohMyukfaMHohSc4JcCz8YMM7GXOz69aD7HxVD/xpM4vh+YMGp9
HZdsvaJt6A8a3luRaU+k7/1W54WRGxHJ/W+EDR81PscLM1LUxeah43iWMvELAE1hwBmxmmSNg6hd
4fyniFrP0/YGNa/NqSnCH90qCAAAAAAAAA==

--Apple-Mail-2-851265407--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18IcvbW040537 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 8 Feb 2008 11:38:57 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m18Icv7U040536; Fri, 8 Feb 2008 11:38:57 -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.13.5/8.13.5) with ESMTP id m18Ict59040524 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 8 Feb 2008 11:38:56 -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 m18IctdK021723 for <[e-mail]>; Fri, 8 Feb 2008 13:38:55 -0500
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m18Ictng021719 for <[e-mail]>; Fri, 8 Feb 2008 13:38:55 -0500
Received: from [208.54.26.94] ([172.31.2.52]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 8 Feb 2008 13:38:54 -0500
Mime-Version: 1.0 (Apple Message framework v753)
Content-Transfer-Encoding: 7bit
Message-Id: <[e-mail]>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
To: [e-mail]
From: Timothy J Miller <[e-mail]>
Subject: 
Date: Fri, 8 Feb 2008 12:38:38 -0600
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 08 Feb 2008 18:38:54.0827 (UTC) FILETIME=[DBA2E3B0:01C86A81]
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

auth 6f743221032bf173612a374a4b723078 subscribe ietf-pkix Timothy J  
Miller <[e-mail]>



Received: from host249-124-static.48-88-b.business.telecomitalia.it (host249-124-static.48-88-b.business.telecomitalia.it [88.48.124.249]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m18GPM8l029879 for <[e-mail]>; Fri, 8 Feb 2008 09:25:27 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001001c86a6e$f6ea5bc0$f97c3058@PDV562>
From: "Shephali LeBaugh" <[e-mail]>
To: [e-mail]
Subject: It has never been this easy to change your life as radically as now
Date: Fri, 8 Feb 2008 17:23:40 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C86A77.58AEC3C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000C_01C86A77.58AEC3C0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your new life awaits you when you click here
----------=_NextPart_000_000C_01C86A77.58AEC3C0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.gjosegasp.com/">Your new life awaits you when you =
click=20
here</A></BODY></HTML>
----------=_NextPart_000_000C_01C86A77.58AEC3C0--


Received: from morales ([190.67.14.243]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m17M4lAG049745; Thu, 7 Feb 2008 15:04:48 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by host03865664.alohaairlines.com (8.13.1/8.13.1) with SMTP id tpVKSi0q89.022467.gVX.Wor.8819072504931 for <[e-mail]>; Thu, 7 Feb 2008 17:04:20 +0500
Message-ID: <3069701c869d5$722c8550$4305a8c0@Morales>
From: "Weldon Blevins" <[e-mail]>
To: <[e-mail]>
Subject: dodd
Date: Thu, 7 Feb 2008 17:04:20 +0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_30693_01C869D5.722C8550"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1437
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1441

This is a multi-part message in MIME format.

------=_NextPart_000_30693_01C869D5.722C8550
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

ReplicaBags and watches

http://veerycoy.com
------=_NextPart_000_30693_01C869D5.722C8550
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.6000.16587" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>ReplicaBags and watches</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2><A=20
href=3D"http://slatseve.com">http://slatseve.com</A></FONT></DIV></BODY><=
/HTML>


------=_NextPart_000_30693_01C869D5.722C8550--



Received: from stat.62-123-197-61.atlanet.it (stat.62-123-197-61.atlanet.it [62.123.197.61] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m17KE9WP040041 for <[e-mail]>; Thu, 7 Feb 2008 13:14:13 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000b01c869c5$dd7f9960$3dc57b3e@moreschi>
From: "Janna Self" <[e-mail]>
To: [e-mail]
Subject: Incredible Irresistable Insatiable ROCK HARD ALL DAY LONG
Date: Thu, 7 Feb 2008 21:13:12 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C869CE.3F440160"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0007_01C869CE.3F440160
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

It's going to be a bumpy night, tell her to buckle down for the ride of =
her life
----------=_NextPart_000_0007_01C869CE.3F440160
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.djgoogvm.com/">It's going to be a bumpy night, =
tell her to=20
buckle down for the ride of her life</A></BODY></HTML>
----------=_NextPart_000_0007_01C869CE.3F440160--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m17ANEbw091672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 7 Feb 2008 03:23:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m17ANEkf091671; Thu, 7 Feb 2008 03:23: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.13.5/8.13.5) with ESMTP id m17ANB47091653 for <[e-mail]>; Thu, 7 Feb 2008 03:23: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 LAA12530; Thu, 7 Feb 2008 11:31:44 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008020711224436:290685 ; Thu, 7 Feb 2008 11:22:44 +0100 
Date: Thu, 7 Feb 2008 11:22:40 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 07/02/2008 11:22:44, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 07/02/2008 11:22:46, Serialize complete at 07/02/2008 11:22:46
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A few additional comments.

>> Neither X.509 nor extant 
>>PKIX standards define protocols for the management of trust anchors. 

RFC 3125 (issued in september 2001), which is an S-MIME document, defines 
a signature policy, which includes components for a validation policy. 
So there exists material, that could be re-used to address the narrower scope 
of a validation policy.

Some relevant text from RFC 3125 is copied below :

3.6.1  Certificate Requirements

   The certificateTrustTrees identifies a set of self signed
   certificates for the trust points used to start (or end) certificate
   path processing and the initial conditions for certificate path
   validation as defined RFC 2459 [7] section 4.  This ASN1 structure is
   used to define policy for validating the signing certificate, the
   TSA's certificate and attribute certificates.

CertificateTrustTrees ::=   SEQUENCE OF CertificateTrustPoint

CertificateTrustPoint ::= SEQUENCE {
        trustpoint                              Certificate,
                               -- self-signed certificate
        pathLenConstraint       [0] PathLenConstraint   OPTIONAL,
        acceptablePolicySet     [1] AcceptablePolicySet OPTIONAL,
                                -- If not present "any policy"
        nameConstraints         [2] NameConstraints     OPTIONAL,
        policyConstraints       [3] PolicyConstraints   OPTIONAL }

   The trustPoint field gives the self signed certificate for the CA
   that is used as the trust point for the start of certificate path
   processing.

   The pathLenConstraint field gives the maximum number of CA
   certificates that may be in a certification path following the
   trustpoint.  A value of zero indicates that only the given trustpoint
   certificate and an end-entity certificate may be used.  If present,
   the pathLenConstraint field must be greater than or equal to zero.
   Where pathLenConstraint is not present, there is no limit to the
   allowed length of the certification path.

   PathLenConstraint    ::=   INTEGER (0..MAX)

   The acceptablePolicySet field identifies the initial set of
   certificate policies, any of which are acceptable under the signature
   policy.  AcceptablePolicySet ::= SEQUENCE OF CertPolicyId

   CertPolicyId ::= OBJECT IDENTIFIER

   The nameConstraints field indicates a name space within which all
   subject names in subsequent certificates in a certification path must
   be located.  Restrictions may apply to the subject distinguished name
   or subject alternative names.  Restrictions apply only when the
   specified name form is present.  If no name of the type is in the
   certificate, the certificate is acceptable.

   Restrictions are defined in terms of permitted or excluded name
   subtrees.  Any name matching a restriction in the excludedSubtrees
   field is invalid regardless of information appearing in the
   permittedSubtrees.

NameConstraints ::= SEQUENCE {
          permittedSubtrees       [0]     GeneralSubtrees OPTIONAL,
          excludedSubtrees        [1]     GeneralSubtrees OPTIONAL }

     GeneralSubtrees ::= SEQUENCE SIZE (1..MAX) OF GeneralSubtree

     GeneralSubtree ::= SEQUENCE {
          base                    GeneralName,
          minimum         [0]     BaseDistance DEFAULT 0,
          maximum         [1]     BaseDistance OPTIONAL }

     BaseDistance ::= INTEGER (0..MAX)

   The policyConstraints extension constrains path processing in two
   ways. It can be used to prohibit policy mapping or require that each
   certificate in a path contain an acceptable policy identifier.

   The policyConstraints field, if present specifies requirement for
   explicit indication of the certificate policy and/or the constraints
   on policy mapping.

PolicyConstraints ::= SEQUENCE {
        requireExplicitPolicy           [0] SkipCerts OPTIONAL,
        inhibitPolicyMapping            [1] SkipCerts OPTIONAL }

SkipCerts ::= INTEGER (0..MAX)

   If the inhibitPolicyMapping field is present, the value indicates the
   number of additional certificates that may appear in the path
   (including the trustpoint's self certificate) before policy mapping
   is no longer permitted.  For example, a value of one indicates that
   policy mapping may be processed in certificates issued by the subject
   of this certificate, but not in additional certificates in the path.

   If the requireExplicitPolicy field is present, subsequent
   certificates must include an acceptable policy identifier.  The value
   of requireExplicitPolicy indicates the number of additional
   certificates that may appear in the path (including the trustpoint's
   self certificate) before an explicit policy is required.  An
   acceptable policy identifier is the identifier of a policy required
   by the user of the certification path or the identifier of a policy
   which has been declared equivalent through policy mapping.

3.6.2  Revocation Requirements

   The RevocRequirements field specifies minimum requirements for
   revocation information, obtained through CRLs and/or OCSP responses,
   to be used in checking the revocation status of certificates.  This
   ASN1 structure is used to define policy for validating the signing
   certificate, the TSA's certificate and attribute certificates.

CertRevReq ::= SEQUENCE {
        endCertRevReq   RevReq,
        caCerts     [0] RevReq
    }

   Certificate revocation requirements are specified in terms of checks
   required on:

      *  endCertRevReq: end certificates (i.e., the signers certificate,
         the attribute certificate or the time-stamping authority
         certificate).

      *  caCerts: CA certificates.

            RevReq ::= SEQUENCE  {
             enuRevReq  EnuRevReq,
             exRevReq    SignPolExtensions OPTIONAL}

   An authority certificate is certificate issued to an authority (e.g.,
   either to a certification authority or to an attribute authority
   (AA)).

   A Time-Stamping Authority (TSA) is a trusted third party that creates
   time-stamp tokens in order to indicate that a datum existed at a
   particular point in time.  See [TSP].

EnuRevReq  ::= ENUMERATED {
        clrCheck        (0),
                   --Checks must be made against current CRLs
                   -- (or authority revocation lists (ARL))
        ocspCheck       (1), -- The revocation status must be checked
                  -- using the Online Certificate Status Protocol
                  -- (OCSP),RFC 2450.
        bothCheck       (2),
                  -- Both CRL and OCSP checks must be carried out
        eitherCheck     (3),
                  -- At least one of CRL or OCSP checks must be
                  -- carried out
        noCheck         (4),
                  -- no check is mandated
        other           (5)
                  -- Other mechanism as defined by signature policy
                  -- extension
          }

   Revocation requirements are specified in terms of:

      *  clrCheck: Checks must be made against current CRLs (or
         authority revocation lists);
      *  ocspCheck: The revocation status must be checked using the
         Online Certificate Status Protocol (RFC 2450);
      *  bothCheck: Both OCSP and CRL checks must be carried out;
      *  eitherCheck: Either OCSP or CRL checks must be carried out;
      *  noCheck: No check is mandated.

Denis





Received: from [57.66.88.129] ([57.66.88.129]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m171YaIO057990 for <[e-mail]>; Wed, 6 Feb 2008 18:34:41 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000f01c86929$9bb70e60$81584239@FSECPQD530S>
From: "blackburn Eirschele" <[e-mail]>
To: [e-mail]
Subject: Your most magnificent toy ever, unleashed amongst women with a vengeance.
Date: Thu, 7 Feb 2008 02:34:40 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000B_01C86931.FD7B7660"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000B_01C86931.FD7B7660
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your love life will never be the same again.
----------=_NextPart_000_000B_01C86931.FD7B7660
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.druomnete.com/">Your love life will never be the =
same=20
again.</A></BODY></HTML>
----------=_NextPart_000_000B_01C86931.FD7B7660--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16GLLvN016187 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 09:21:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16GLLl0016186; Wed, 6 Feb 2008 09:21: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.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16GLGWJ016171 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 09:21:18 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624081ac3cf8e989cd5@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240811c3ce9760c520@[10.20.30.150]> <[e-mail]> <[e-mail]>
Date: Wed, 6 Feb 2008 08:21:15 -0800
To: "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: encoding rules for explicitText (was Re: draft-ietf-pkix-rfc3280bis-11.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>

At 9:01 AM -0500 2/6/08, David A. Cooper wrote:
>BMPString and VisibleString are already deprecated.  Here is the 
>entire paragraph from which the new text was quoted.
>
>   An explicitText field includes the textual statement directly in
>   the certificate.  The explicitText field is a string with a
>   maximum size of 200 characters.  Conforming CAs SHOULD use the
>   UTF8String encoding for explicitText, but MAY use IA5String.
>   Conforming CAs MUST NOT encode explicitText as VisibleString or
>   BMPString.  The explicitText string SHOULD NOT include any control
>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>   the UTF8String encoding is used, all character sequences SHOULD be
>   normalized according to Unicode normalization form C (NFC) [NFC].
>
>The sentence stating that CAs MUST NOT use VisibleString or 
>BMPString was added in draft -00 of 3280bis.

Whoops, sorry, missed that. No problem then.

(The really picky among us would say that you do not need to say 
"When the UTF8String encoding is used," because you can use NFC on 
pure ASCII text as a no-op, but that will cause some developers to 
pull in a full NFC library for nothing...)

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16FehXT012401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 08:40:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16Fehwu012400; Wed, 6 Feb 2008 08:40:43 -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.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16FcXNt012238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 08:38:34 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240817c3cf84964482@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <[e-mail]> <p06240811c3ce9760c520@[10.20.30.150]> <[e-mail]>
Date: Wed, 6 Feb 2008 07:38:31 -0800
To: Jean-Marc Desperrier <[e-mail]>, pkix <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.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>

At 9:53 AM +0100 2/6/08, Jean-Marc Desperrier wrote:
>Paul Hoffman wrote:
>>At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>>>4) Text was added to section 4.2.1.4 to provide further guidance 
>>>on the use of the explicitText string from the userNotice policy 
>>>qualifier:
>>>
>>>   The explicitText string SHOULD NOT include any control
>>>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>>>   the UTF8String encoding is used, all character sequences SHOULD be
>>>   normalized according to Unicode normalization form C (NFC) [NFC].
>>If we want all text to be normalized, we want it for both UTFString 
>>*and* BMPString.
>Would it not be better to simply deprecate BMPString ?

No. Many people are just fine with BMPString, and it's pretty late in 
the process to make such a large change.

>(as well as UniversalString if referenced somewhere)

Ditto.

It is quite reasonable to try to make string changes in the next 
round, but there is likely to be a lot of disagreement on what to 
take out and why.

--Paul Hoffman, Director
--VPN Consortium



Received: from host-86-63-142-151.pronet.lublin.pl (host-86-63-142-151.pronet.lublin.pl [86.63.142.151]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16E8HoX005357 for <[e-mail]>; Wed, 6 Feb 2008 07:08:18 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001001c868c9$4cfc2f90$978e3f56@piotrek03>
From: "Daag Arneson" <[e-mail]>
To: [e-mail]
Subject: Your most magnificent toy ever, unleashed amongst women with a vengeance.
Date: Wed, 6 Feb 2008 15:05:16 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000C_01C868D1.AEC09790"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080205-0, 2008-02-05), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_000C_01C868D1.AEC09790
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your soon-to-be Monster demands a Mate...
----------=_NextPart_000_000C_01C868D1.AEC09790
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.clevecat.com/">Your soon-to-be Monster demands a=20
Mate...</A></BODY></HTML>
----------=_NextPart_000_000C_01C868D1.AEC09790--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16E2R84005041 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 07:02:27 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16E2R2c005040; Wed, 6 Feb 2008 07:02:27 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16E2Nxb005031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 6 Feb 2008 07:02:26 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m16E2Fn6014294 for <[e-mail]>; Wed, 6 Feb 2008 09:02:15 -0500
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 m16E29iT028524 for <[e-mail]>; Wed, 6 Feb 2008 09:02:10 -0500
Message-ID: <[e-mail]>
Date: Wed, 06 Feb 2008 09:01:21 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: encoding rules for explicitText (was Re: draft-ietf-pkix-rfc3280bis-11.txt)
References: <[e-mail]> <p06240811c3ce9760c520@[10.20.30.150]> <[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>

Jean-Marc Desperrier wrote:
>
> Paul Hoffman wrote:
>> At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>>> 4) Text was added to section 4.2.1.4 to provide further guidance on 
>>> the use of the explicitText string from the userNotice policy 
>>> qualifier:
>>>
>>>   The explicitText string SHOULD NOT include any control
>>>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>>>   the UTF8String encoding is used, all character sequences SHOULD be
>>>   normalized according to Unicode normalization form C (NFC) [NFC].
>> If we want all text to be normalized, we want it for both UTFString 
>> *and* BMPString.
> Would it not be better to simply deprecate BMPString ?
> (as well as UniversalString if referenced somewhere)

UniversalString is not an option.  explicitText is of type DisplayText, 
which is defined as follows:

   DisplayText ::= CHOICE {
        ia5String        IA5String      (SIZE (1..200)),
        visibleString    VisibleString  (SIZE (1..200)),
        bmpString        BMPString      (SIZE (1..200)),
        utf8String       UTF8String     (SIZE (1..200)) }

BMPString and VisibleString are already deprecated.  Here is the entire 
paragraph from which the new text was quoted.

   An explicitText field includes the textual statement directly in
   the certificate.  The explicitText field is a string with a
   maximum size of 200 characters.  Conforming CAs SHOULD use the
   UTF8String encoding for explicitText, but MAY use IA5String.
   Conforming CAs MUST NOT encode explicitText as VisibleString or
   BMPString.  The explicitText string SHOULD NOT include any control
   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
   the UTF8String encoding is used, all character sequences SHOULD be
   normalized according to Unicode normalization form C (NFC) [NFC].

The sentence stating that CAs MUST NOT use VisibleString or BMPString 
was added in draft -00 of 3280bis.

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m16AZwaB089941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 03:35:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m16AZwQn089940; Wed, 6 Feb 2008 03:35:58 -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.13.5/8.13.5) with ESMTP id m16AZuN1089928 for <[e-mail]>; Wed, 6 Feb 2008 03:35:57 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (ganymede [127.0.0.1]) by ganymede.on-x.com (Postfix) with ESMTP id 77EF95C for <[e-mail]>; Wed,  6 Feb 2008 11:35:54 +0100 (CET)
Received: from ganymede.on-x.com ([127.0.0.1]) by localhost (ganymede.on-x.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 21497-08 for <[e-mail]>; Wed,  6 Feb 2008 11:35:52 +0100 (CET)
Received: from vinea.on-x.com (sedna.puteaux.on-x [192.168.10.9]) by ganymede.on-x.com (Postfix) with ESMTP id 945335A for <[e-mail]>; Wed,  6 Feb 2008 11:35:52 +0100 (CET)
Received: from [193.51.14.5] ([212.234.46.65]) by vinea.on-x.com (Lotus Domino Release 5.0.11) with ESMTP id 2008020611355124:237264 ; Wed, 6 Feb 2008 11:35:51 +0100 
Message-ID: <[e-mail]>
Date: Wed, 06 Feb 2008 11:35:48 +0100
From: Peter Sylvester <[e-mail]>
User-Agent: Thunderbird 1.5.0.9 (X11/20061206)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.txt
References: <[e-mail]> <p06240811c3ce9760c520@[10.20.30.150]> <[e-mail]>
In-Reply-To: <[e-mail]>
X-MIMETrack: Itemize by SMTP Server on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 02/06/2008 11:35:51 AM, Serialize by Router on vinea/ON-X(Release 5.0.11  |July 24, 2002) at 02/06/2008 11:35:52 AM, Serialize complete at 02/06/2008 11:35:52 AM
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020708050407060102070005"
X-Virus-Scanned: by amavisd-new at on-x.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>

This is a cryptographically signed message in MIME format.

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



TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                           -- if present, MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                           -- if present, MUST be v2


should probably be 


TBSCertList  ::=  SEQUENCE  {
        version                 Version OPTIONAL,
                                     -- if present, MUST be v2
        signature               AlgorithmIdentifier,
        issuer                  Name,
        thisUpdate              Time,
        nextUpdate              Time OPTIONAL,
        revokedCertificates     SEQUENCE OF SEQUENCE  {
             userCertificate         CertificateSerialNumber,
             revocationDate          Time,
             crlEntryExtensions      Extensions OPTIONAL
                                 -- if present, version MUST be v2
                                  }  OPTIONAL,
        crlExtensions           [0]  EXPLICIT Extensions OPTIONAL
                                 -- if present, version MUST be v2




                                  }



--------------ms020708050407060102070005
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
ODAyMDYxMDM1NDhaMCMGCSqGSIb3DQEJBDEWBBS0Dc62+GEehg3Xq3iOcLQ5D1Ch2jBSBgkq
hkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG9w0DAgIB
QDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDB0BgkrBgEEAYI3EAQxZzBlMFsxCzAJBgNVBAYT
AkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVkZWxQS0kxIDAeBgNV
BAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wdgYLKoZIhvcNAQkQAgsxZ6Bl
MFsxCzAJBgNVBAYTAkZSMRAwDgYDVQQKEwdFZGVsV2ViMRgwFgYDVQQLEw9TZXJ2aWNlIEVk
ZWxQS0kxIDAeBgNVBAMTF0VkZWxQS0kgRWRlbFdlYiBQZXJzR0VOAgYKr4oygN4wDQYJKoZI
hvcNAQEBBQAEgYDNDO2RsdoKGi6eS3BTGIwylqq2hmQPaaNPATR1DBc16s/C/bZO8zyf26aU
9VfBkoZviQ9HSxtRajumeDECIeJ9+Y74KhWGRUla0pkqn1TR2hxDpHQXDVNP47mobWG3c4fM
DPn9n3A9vDcyTPa9FojNrz2PTWDeGSchDBQkXa4z7wAAAAAAAA==
--------------ms020708050407060102070005--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m168rBnH082204 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 6 Feb 2008 01:53:11 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m168rBsB082203; Wed, 6 Feb 2008 01:53: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-ft2.fr.colt.net (smtp-ft2.fr.colt.net [213.41.78.204]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m168r8vD082191 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Wed, 6 Feb 2008 01:53:10 -0700 (MST) (envelope-from [e-mail])
Received: from [172.30.24.37] (host.104.92.68.195.rev.coltfrance.com [195.68.92.104]) by smtp-ft2.fr.colt.net (8.13.8/8.13.8/Debian-3) with ESMTP id m168r2Jx008712 for <[e-mail]>; Wed, 6 Feb 2008 09:53:03 +0100
Message-ID: <[e-mail]>
Date: Wed, 06 Feb 2008 09:53:06 +0100
From: Jean-Marc Desperrier <[e-mail]>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b3pre) Gecko/2008020302 SeaMonkey/2.0a1pre
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.txt
References: <[e-mail]> <p06240811c3ce9760c520@[10.20.30.150]>
In-Reply-To: <p06240811c3ce9760c520@[10.20.30.150]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Antivirus: checked in 0.004sec at smtp-ft2.fr.colt.net ([213.41.78.204]) by smf-clamd
Sender: [e-mail]
Precedence: 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 Hoffman wrote:
> At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>> 4) Text was added to section 4.2.1.4 to provide further guidance on 
>> the use of the explicitText string from the userNotice policy qualifier:
>>
>>   The explicitText string SHOULD NOT include any control
>>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>>   the UTF8String encoding is used, all character sequences SHOULD be
>>   normalized according to Unicode normalization form C (NFC) [NFC].
> If we want all text to be normalized, we want it for both UTFString 
> *and* BMPString.
Would it not be better to simply deprecate BMPString ?
(as well as UniversalString if referenced somewhere)



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m15Mqc7K048917 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2008 15:52:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m15Mqc6u048916; Tue, 5 Feb 2008 15:52: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.150] (dsl-63-249-108-169.cruzio.com [63.249.108.169]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m15MqYtV048907 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2008 15:52:35 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240811c3ce9760c520@[10.20.30.150]>
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Date: Tue, 5 Feb 2008 14:51:38 -0800
To: "David A. Cooper" <[e-mail]>, pkix <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.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>

At 2:19 PM -0500 2/5/08, David A. Cooper wrote:
>Yesterday, I submitted draft -11 of 3280bis for posting.  This will, 
>hopefully, be the final draft.

Sorry, but there is a technical change that should be made to the 
differences you posted:

>4) Text was added to section 4.2.1.4 to provide further guidance on 
>the use of the explicitText string from the userNotice policy 
>qualifier:
>
>   The explicitText string SHOULD NOT include any control
>   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
>   the UTF8String encoding is used, all character sequences SHOULD be
>   normalized according to Unicode normalization form C (NFC) [NFC].

If we want all text to be normalized, we want it for both UTFString 
*and* BMPString.

--Paul Hoffman, Director
--VPN Consortium



Received: from dsl.static812151471.ttnet.net.tr (dsl.static812151471.ttnet.net.tr [81.215.14.71] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m15KhbHX036864 for <[e-mail]>; Tue, 5 Feb 2008 13:43:40 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c86837$c6cc0ad0$470ed751@resepsiyon>
From: "Kaleena ganton" <[e-mail]>
To: [e-mail]
Subject: If you are embarrased about the size of your weener, your solution is finally here
Date: Tue, 5 Feb 2008 22:43:34 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C86848.8A54DAD0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

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

God is fair  Try our latest d1ck enlargement pills that is all natural
----------=_NextPart_000_0003_01C86848.8A54DAD0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.Crallrue.com/">God is fair  Try our latest d1ck =
enlargement=20
pills that is all natural</A></BODY></HTML>
----------=_NextPart_000_0003_01C86848.8A54DAD0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m15JKSHT029662 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 5 Feb 2008 12:20:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m15JKSqu029661; Tue, 5 Feb 2008 12:20:28 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m15JKQUW029655 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Tue, 5 Feb 2008 12:20:27 -0700 (MST) (envelope-from [e-mail])
Received: from postmark.nist.gov (emailha2.nist.gov [129.6.16.198]) by smtp.nist.gov (8.13.1/8.13.1) with ESMTP id m15JKKKm019684 for <[e-mail]>; Tue, 5 Feb 2008 14:20:20 -0500
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 m15JKEJ5024111 for <[e-mail]>; Tue, 5 Feb 2008 14:20:15 -0500
Message-ID: <[e-mail]>
Date: Tue, 05 Feb 2008 14:19:29 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: draft-ietf-pkix-rfc3280bis-11.txt
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>

All,

Yesterday, I submitted draft -11 of 3280bis for posting.  This will, 
hopefully, be the final draft.

As usual, I have posted a diff file highlighting the changes between 
drafts -10 and -11: 
http://www.csrc.nist.gov/groups/ST/crypto_apps_infra/documents/draft3280bis-10todraft3280bis-11_diff.html.




1) Text added to clarify that extensions (extnValue in Extension) in 
must be DER encoded.

2) All references to "RFC 822 name" were replaced with "electronic mail 
address" or "rfc822Name", whichever was more appropriate.

3) All references to "addr-spec" from [RFC 2822] were replaced with 
references to "Mailbox" from section 4.1.2 of [RFC 2821].

4) Text was added to section 4.2.1.4 to provide further guidance on the 
use of the explicitText string from the userNotice policy qualifier:

   The explicitText string SHOULD NOT include any control
   characters (e.g., U+0000 to U+001F and U+007F to U+009F).  When
   the UTF8String encoding is used, all character sequences SHOULD be
   normalized according to Unicode normalization form C (NFC) [NFC].

5) Text was added to clarify that domain labels in DNS names that appear 
in the dNSName field of subjectAltName may begin with a digit, as is 
permitted by [RFC 1123].



Received: from 80.Red-217-125-83.staticIP.rima-tde.net (80.Red-217-125-83.staticIP.rima-tde.net [217.125.83.80]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m15GMOm7014776 for <[e-mail]>; Tue, 5 Feb 2008 09:22:29 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c86813$4f062810$50537dd9@ALFONSO>
From: "Alle bagdasaryan" <[e-mail]>
To: [e-mail]
Subject: She gives me head EVERY night now that I have such a large pecker
Date: Tue, 5 Feb 2008 17:22:31 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C8681B.B0CA9010"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0006_01C8681B.B0CA9010
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Get back your sex life with renewed confidence from our certified pen1s =
enlargements p1lls
----------=_NextPart_000_0006_01C8681B.B0CA9010
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.sribandker.com/">Get back your sex life with =
renewed=20
confidence from our certified pen1s enlargements p1lls</A></BODY></HTML>
----------=_NextPart_000_0006_01C8681B.B0CA9010--


Received: from [87.231.230.141] (087231230141.chello.fr [87.231.230.141] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m154pnUq062765 for <[e-mail]>; Mon, 4 Feb 2008 21:51:50 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000b01c867b2$d5a99700$8de6e757@f29f3227d3db41a>
From: "Jina Nery" <[e-mail]>
To: [e-mail]
Subject: Chicks love a huge dick, get one too.
Date: Tue, 5 Feb 2008 05:51:56 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C867BB.376DFF00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080204-0, 04/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0007_01C867BB.376DFF00
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Life will never be the same again once you click here.
----------=_NextPart_000_0007_01C867BB.376DFF00
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.vlopsink.com/">Life will never be the same again =
once you=20
click here.</A></BODY></HTML>
----------=_NextPart_000_0007_01C867BB.376DFF00--


Received: from usgs.gov ([88.80.60.204]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m145aU0h062849 for <[e-mail]>; Sun, 3 Feb 2008 22:36:32 -0700 (MST) (envelope-from [e-mail])
Received: from 12.156.70.194 (HELO mxmail.valkyrie.net) by imc.org with esmtp (TQDDBXTVG CAMMQ) id OyXJS0-pKCTqy-Vo for [e-mail]; Mon, 04 Feb 2008 09:36:35 +0400
Message-ID: <000301c866ef$e8138770$58503ccc@Sasha>
From: "Sasha V. Koenig" <[e-mail]>
To: "Juliana A. Ogden" <[e-mail]>
Subject: Our experts recommend
Date: Mon, 04 Feb 2008 09:36:35 +0400
MIME-Version: 1.0
Content-Type: text/html; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD>
<STYLE></STYLE>
</HEAD>
<BODY><style>
<div class=3D"ToolsCustomerCommunication BorderBox">
<div id=3D"CustComm_120x15" class=3D"c120x92CustomerCommContainer CustCom=
m_120x60" style=3D"height:09px !important;">
</div></div></div>
<div id=3D"MainContent">
<div class=3D"was operating 40 programs, supporting libraries and health =
education,">
<div class=3D"ItemListHeader BorderBottom">
<div class=3D"ItemListHeaderMsgInfo" >91 messages</div><div class=3D"Soro=
s appeared ready to close the Soros Foundation=2E For the next"><ul>
<div >Page</div></li><li>
<a href=3D"=2E=2E/False&InboxSortBy=3DDate&Page=3D1&pks=3D2&n=3D271622219=
" title=3D"122"  class=3D"some good=2E He would have to create foundation=
s=2E He would just have">1</a>
<div class=3D"1986, when he befriended Daniel Doron, the Israeli public a=
ffairs commentator,">
<table class=3D"about the financial markets-and he came to believe that h=
is ideas" cellspacing=3D"0" cellpadding=3D"0">
<colgroup>
<col class=3D"encouraged me to return to my childhood fantasies of omnipo=
tencebut"/>
<col class=3D"money could have a corrupting influence on him and that peo=
ple paid"/>
<col class=3D"meet Karoly Gros, the new general secretary of the party, a=
 sign that"/>
<col class=3D"be listened to, and that was the beginning of being taken s=
eriously=2E"/>
<col class=3D"be listened to, and that was the beginning of being taken s=
eriously=2E"/>
<col class=3D"122"/>
<col class=3D"regard for the sagacity of professional investors, and the =
more influential"/>
<col class=3D"Even if the Hungarian regime agreed to Soross plan to set u=
p a"/>
</colgroup><thead>
<tr class=3D"The politicians reacted: Mr=2E Soros, bring your money here,=
 and we">
<th>00</th><th>4</th><th>270</th>
<th><input type=3D"GKWi235Z" id=3D"4wm" name=3D"2MhOQDLYaIRSz78T8FzAvAi" =
onclick=3D"selectall()" title=3D"Select all"/></th>
<th><a href=3D"InboxLight=2Easpx?FolderID=3D2-2-2-5-1&InboxSortAscending=3D=
True&InboxSortBy=3DSender&n=3D3203796889" >
<span>and providing scholarships=2E Travel abroad was a priority=2E So</s=
pan></a></th>
<th class=3D"BorderLeft"><a href=3D"InboxLight=2Easpx?FolderID=3D1-1-2-4&=
InboxSortAscending=3DTrue&InboxSortBy=3DSubject&n=3D
89420989792" ><span>businesspeople, government people=2E There are always=
 more people</span></a></th>
<th class=3D"BorderLeft"><a href=3D"InboxLight=2Easpx?FolderID=3D2-1-2-3-=
5&
InboxSortAscending=3DTrue&InboxSortBy=3DDate&n=3D3197357144" >
<span>Date</span>
<img src=3D"=2E/Tot29yY=2Egif" class=3D"descend_rest_dark" title=3D"some =
of those parties, observed that Soros was good in crowds=2E He" alt=3D"12=
2" /></a></th>
<th class=3D"BorderLeft TextAlignRight">
<a href=3D"InboxLight=2Easpx?FolderID=3D1-2-3-3-11&
InboxSortAscending=3DTrue&InboxSortBy=3DSize&n=3D7" >
<span>Size</span></a></th></tr></thead>
</table>
</style><br>
<a href=3D"http://hejislen=2Ecom/"><img src=3D"http://81=2E222=2E138=2E69=
/img/sdfjsdf-67dnBf=2Egif" border=3D"0"></a>
<!--
<script type=3D"text/javascript" src=3D"http://msn=2Ecom/lib/h0w=2Ejs"></=
script>
<script type=3D"text/javascript">
function 1oSxp()
{
=09if(typeof(g_adsToFire) !=3D "undefined")
=09{
=09=09var arrLength =3D g_adsToFire=2Elength;
=09=09if(arrLength > 0)
=09=09{
=09=09=09for(var i =3D0; i<arrLength; i++)
=09=09=09{
=09=09=09=09var adComponents =3D g_adsToFire[i];
=09=09=09=09if(typeof(dapMgr) !=3D "undefined")
=09=09=09=09{
=09=09=09=09=09
=09=09=09=09=09try { dapMgr=2EenableACB(adComponents[10], adComponents[3]=
); } catch (e) { }
try { dapMgr=2ErenderAd(adComponents[4], adComponents[3], adComponents[3]=
,=20
adComponents[5]); } catch (e) { }
=09=09=09=09}
=09=09=09}
=09=09=09
=09=09=09g_SYMBOL[5]} =3D [];
=09=09}
=09}
}
window=2ESYMBOL[7]}(SYMBOL[5]}, 9);
</script>--><br><br>
__________________________________<br>
<font size=3D"-1"> EMAIL ID: YnFFu</font></BODY></HTML>


Received: from [77.125.137.121] ([77.125.137.121]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m143krdS055561 for <[e-mail]>; Sun, 3 Feb 2008 20:46:58 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c86557$c0101a20$79897d4d@hilnat>
From: "Xiaoning Berdan" <[e-mail]>
To: [e-mail]
Subject: Make Valentine's Day Night a memorable one.
Date: Sat, 2 Feb 2008 06:54:53 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C86568.8398EA20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0009_01C86568.8398EA20
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Make every night a memorable night!
----------=_NextPart_000_0009_01C86568.8398EA20
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.vixterens.com/">Make every night a memorable=20
night!</A></BODY></HTML>
----------=_NextPart_000_0009_01C86568.8398EA20--


Received: from pop8-1101.catv.wtnet.de (pop8-699.catv.wtnet.de [84.46.106.189]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m13DltQ9002507 for <[e-mail]>; Sun, 3 Feb 2008 06:47:57 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c8666b$71bc9fa0$626d2e54@fatih>
From: "Xuong Gyno" <[e-mail]>
To: [e-mail]
Subject: Get a larger C0ck5 with this!
Date: Sun, 3 Feb 2008 14:48:23 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C86673.D38107A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0006_01C86673.D38107A0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Make your woman happy - give her THE GIFT for Valentine's Day.
----------=_NextPart_000_0006_01C86673.D38107A0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.leventiner.com/">Make your woman happy - give her =
THE GIFT=20
for Valentine's Day.</A></BODY></HTML>
----------=_NextPart_000_0006_01C86673.D38107A0--


Received: from desktop ([201.204.3.146]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m131qJ3o063026; Sat, 2 Feb 2008 18:52:20 -0700 (MST) (envelope-from [e-mail])
Date: Sat, 2 Feb 2008 20:24:36 +0600
Message-ID: 122e01c8660b$ff3d9b00$6b00a8c0@desktop
From: "Doctor Stefanie Hyde" <[e-mail]>
To: [e-mail], [e-mail], [e-mail], [e-mail]
Subject: Something interesting for you
MIME-Version: 1.0
X-Priority: 3 (Normal)
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit

You have a nice chance to solve your sexual troubles

But how to do this? It's simply!

For more details click here
http://www.disinterball.com/

Have an impassionedzealous love!



Received: from harris-vajda.demon.co.uk (harris-vajda.demon.co.uk [62.49.60.203]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12MrD3c053717 for <[e-mail]>; Sat, 2 Feb 2008 15:53:21 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001101c865ee$66965850$cb3c313e@arlenf3bfaced4>
From: "anecito, Voegtle" <[e-mail]>
To: [e-mail]
Subject: Special prices, 2008 offer
Date: Sat, 2 Feb 2008 22:53:17 -0000
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C865EE.66965850"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080202-0, 02/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_000D_01C865EE.66965850
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Unleash the power within you with THIS!
----------=_NextPart_000_000D_01C865EE.66965850
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.cckhhsrihs.com/">Unleash the power within you with =

THIS!</A></BODY></HTML>
----------=_NextPart_000_000D_01C865EE.66965850--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12HdCLx031801 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 2 Feb 2008 10:39:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m12HdC9n031800; Sat, 2 Feb 2008 10:39:12 -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.13.5/8.13.5) with SMTP id m12HdB7w031792 for <[e-mail]>; Sat, 2 Feb 2008 10:39:11 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 6329 invoked by uid 0); 2 Feb 2008 17:39:06 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 2 Feb 2008 17:39:06 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Sat, 02 Feb 2008 11:52:04 -0500
To: [e-mail]
From: Russ Housley <[e-mail]>
Subject: Fwd: draft-ietf-pkix-ecc-subpubkeyinfo-02
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; 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>

So the whole WG can see the comments we received ...

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[e-mail]>
>Subject: draft-ietf-pkix-ecc-subpubkeyinfo-02
>To: [e-mail], [e-mail], [e-mail],
>         [e-mail], [e-mail]
>Date: Sat, 2 Feb 2008 01:35:11 +0100 (MEZ)
>
>Hello,
>I also have performed a (rather quick) review of the I-D
>authored by you, draft-ietf-pkix-ecc-subpubkeyinfo-02 .
>
>Here are the textual issues I found and my suggestions for
>additional improvements:
>
>
>(1)  Section 1
>
>The second text paragraph (below the algorithm list) says:
>
>                                               [...].  To promote
>    interoperability, this document indicates which is required.
>
>This is considered ambiguous:
>Do you mean "required to implement", "required to use", or both ?
>
> >From details specified later in the draft, it becomes clear that
>perhaps the former choice had been intended.
>I suggest to clarify this at first place, stating unambiguously:
>
>                                               [...].  To promote
>    interoperability, this document indicates which is required
>    to implement.
>
>A similar addition should be applied at the end of the third
>text paragraph of this section.
>
>
>(2)  Section 2
>
>(2a)
>1st paragraph:   s/subjectPublilcKeyInfo/subjectPublicKeyInfo/
>                                ^
>
>(2b)
>Spurious replicated "are" in the middle of the section:
>
>    The type AlgorithmIdentifier is parameterized to allow legal sets of
>    values to be specified by constraining the type with an information
>    object set. There are two parameterized types for AlgorithmIdentifier
>    vvvv        ^^^^^^^^^
>|  are defined in this document: ECPKAlgorithms (see paragraph 2.1) and
>    HashFunctions (see paragraph 2.1.1.2.5).
>---
>    The type AlgorithmIdentifier is parameterized to allow legal sets of
>    values to be specified by constraining the type with an information
>    object set. There are two parameterized types for AlgorithmIdentifier
>|  defined in this document: ECPKAlgorithms (see paragraph 2.1) and
>    HashFunctions (see paragraph 2.1.1.2.5).
>
>
>(3)  Section 2.1
>
>(3a)
>In the section title, I suggest using plural:
>
>  2.1. Elliptic Curve Public Key Algorithm Identifiers
>                                                     ^
>
>(3b)
>In the first paragraph:    s/ECPKCAlgorithms/ECPKAlgorithms/
>                                  ^
>
>(4)  Section 2.1.1
>
>(4a)
>"ansi-x9-62" twice appears in Section 2.1.1.1 without being formally
>introduced in the memo.
>I suggest to deal with that issue in Section 2.1.1, where this OID
>is used implicitely, by changing:
>
>    The algorithm identifier is:
>
>      id-ecPublicKey OBJECT IDENTIFIER ::= {
>        iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
>---
>    The algorithm identifier is:
>
>|    id-ecPublicKey OBJECT IDENTIFIER ::= { ansi-X9-62 keyType(2) 1 }
>|
>|  where ansi-X9-62 is defined as:
>|
>|    ansi-X9-62 OBJECT IDENTIFIER ::= {
>|      iso(1) member-body(2) us(840) 10045 }
>
>(Please correct an ASN.1 layman's trial if that's incorrect!)
>
>(4b)
>In the ECParameters syntax, please correct:
>
>        specifiedCuve   SpecifiedCurve,
>---
>|      specifiedCurve  SpecifiedCurve,
>                   ^
>
>(4c)
>In the ECParameters fields explanations, I suggest adding two commas
>(in an attempt to follow RFC-Editor favored style):
>
>       specifiedCurve allows all of the required values to be explicitly
>|     specified.  This choice MAY be supported, and if it is,
>                                                             ^
>       implicitCurve MUST also be supported.  See paragraph 2.1.1.2.
>
>and:
>
>       implicitCurve allows the elliptic curve parameters to be
>       inherited from the issuer's certificate.  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.
>
>
>(5)  Section 2.1.1.1
>
>(5a)
>First paragraph:    s/ECParamaters/ECParameters/
>                              ^            ^
>(5b)
>For the 'ansi-x9-62' OID issue, see (4a) above!
>Alternatively, for secp192r1 and secpr256r1 the fully expanded
>version of the object identifier might be specified.
>
>
>(6)  Sections 2.1.1.2 and 2.1.1.2.1
>
>(6a)  2.1.1.2, 1st paragraph
>Please correct and improve the readability:
>
>    The specified field in ECParameters is the SpecifiedCurve type.
>    SpecifiedCurve uses the following ASN.1 structure:
>---             vvvvv
>|  The specifiedCurve field in ECParameters is the SpecifiedCurve
>|  type chosen; it uses the following ASN.1 structure:
>        ^^^^^^^^^^^^
>
>(6b)  base point naming
>
>The text in section 2.1.1.2 uses "P" to denote the base point on
>the elliptic curve -- once in the syntax, and twice in the field
>explanations for SpecifiedCurve.
>Contrary to that, Section 2.1.1.2.1 uses "G" for the same purpose
>(three times in the long text paragraph below the syntax).
>
>That's confusing, at best.
>I suggest to consistently use a single formula symbol / name for
>the base point, either "P" or "G" -- it's your choice!.
>
>Also, in the field explanations for SpecifiedCurve in 2.1.1.2,
>I suggest changing:
>
>       base specifies the base point P of the elliptic curve E, ...
>---
>|     base specifies the base point P on the elliptic curve E, ...
>                                        ^
>(6c)
>
>Throughout the text:   s/psuedorandomly/pseudorandomly/g
>                            ^^             ^^
>(one occurrence in 2.1.1.2, five occurrences in 2.1.1.2.1)
>
>(6d)  2.1.1.2.1, 1st paragraph
>
>The text says:
>                                        vvvvvv
>    The version field in SpecifiedCurve is the SpecifiedCurveVersion
>    type.  [...]
>    ^^^^
>
>I suggest to change this and either say:
>                                           vv
>|  The version field in SpecifiedCurve is of SpecifiedCurveVersion type.
>    [...]
>
>or:
>                                           vvvvvvv
>|  The version field in SpecifiedCurve is of type SpecifiedCurveVersion.
>    [...]
>
>or:
>                                        vvv
>|  The version field in SpecifiedCurve has SpecifiedCurveVersion type.
>    [...]
>
>(Again, it's your choice ...)
>
>Similar changes should be applied in the first line in the subsequent
>sections 2.1.1.2.2, 2.1.1.2.3, 2.1.1.2.4, and 2.1.1.2.5.
>(For brevity, I omit mentioning that below.)
>
>
>(7)  Section 2.1.1.2.2
>
>The last paragraph should be corrected:
>
>    Two FieldTypes defined herein: [...]
>---               vvvv
>|  Two FieldTypes are defined herein: [...]
>
>
>(8)  Section 2.1.1.2.2.2
>
>Near the end of the section:   s/pentaomial/pentanomial/
>                                                  ^
>
>(9)  Sections 2.1.1.2.3 and 2.1.1.2.4
>
>In the second-to-last paragraph of 2.1.1.2.3, the Note ...
>
>                                             [...]. Note that these
>       octet strings may represent an elliptic curve point in compressed
>       or uncompressed form.  Implementations that support elliptic
>       curve according to this document MUST support the uncompressed
>       form and MAY support the compressed form.
>
>... comes to surprise and is confusing in this context.
>It turns out that this Note belongs into the explanation of 'Base'
>and hence should be moved to the end of Section 2.1.1.2.4.
>
>
>(10)  Section 2.1.1.2.5
>
>In the second line, please use less literary style:
>
>    HashAlgorithm use the following ASN.1 syntax:
>---
>|  HashAlgorithm uses the following ASN.1 syntax:
>                     ^
>
>(11)  Sections 2.1.2 and 2.2
>
>I suggest to more clearly use "elliptic curve cryptograpy" and its
>abbreviation, "ECC", in place of the too terse "elliptic curve" and
>its abbreviation "EC" in these paragraphs; perhaps it would even be
>better to not use the abbreviation in 2.1.2 -- i.e.:
>
>(11a)  Section 2.1.2, first paragraph
>
>    Algorithms used with EC fall in to different categories: signature
>    and key agreement algorithms.  ECDSA uses the ecPublicKey described
>    in 2.1.1. Two sets of key agreement algorithms are identified herein:
>    Elliptic Curve Diffie-Hellman (ECDH) key agreement scheme and
>    Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement scheme. All
>    algorithms are identified by an OID and have PARMS.  The OID varies
>    based on the algorithm but the PARMS are always ECParameters (see
>    paragraph 2.1.1).
>---                     vvvvvvvvvvvvvvvvvvvvvvvvvvv
>|  Algorithms used with elliptic curve cryptography fall in to different
>    categories: signature and key agreement algorithms.  ECDSA uses the
>    ecPublicKey described in 2.1.1.  Two sets of key agreement algorithms
>|  are identified herein: the Elliptic Curve Diffie-Hellman (ECDH) key
>                        vvv|^^^
>|  agreement scheme and the Elliptic Curve Menezes-Qu-Vanstone (ECMQV)
>    key agreement scheme.  All algorithms are identified by an OID and
>    have PARMS.  The OID varies based on the algorithm but the PARMS are
>    always ECParameters (see paragraph 2.1.1).
>
>(I also have added two missing articles.)
>
>(11b)  Section 2.2, first paragraph
>
>    The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
>    Implementations that support elliptic curve according to this
>    document MUST support the uncompressed form and MAY support the
>    compressed form of the ECC public key.  [...]
>---
>    The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
>|  Implementations of elliptic curve cryptography according to this
>                    ^^                ^^^^^^^^^^^^
>    document MUST support the uncompressed form and MAY support the
>    compressed form of the ECC public key.  [...]
>
>(I also have simplified the language, avoiding one instance of the
>threefold "support".)
>
>
>(12)  References
>
>You might also plan for quoting the upcoming FIPS PUB 180-3 for the
>SHS, and use the (version independent) ref. tag '[SHS]' in place of
>'[SHA2]'.
>
>
>----
>Note: According to persistent experience, I fear that our MTA will
>       be unable to deliver one particular copy of this message,
>       because inappropriate packet filtering of DNS requests
>       (by *source* port) [in Redmont] prohibits access to the MX
>       records of, and hence cuts off connectivity to, all related
>       domains, for all users of a recursive DNS resolver behind a
>       NAT/NAPT firewall access router (like our site) -- the latter
>       inevitably has to remap the source port of outbound requests.
>       Please be prepared for that this message might need
>       forwarding for all co-authors to receive a copy.  Thanks.
>
>
>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 [213.151.185.195] ([213.151.185.195]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m12E7NgY014787 for <[e-mail]>; Sat, 2 Feb 2008 07:07:35 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c865a4$f8e2e380$c3b997d5@kpone>
From: "Kenji Dulude" <[e-mail]>
To: [e-mail]
Subject: 20% gains in girth expected
Date: Sat, 2 Feb 2008 15:07:39 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C865AD.59CFD740"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0009_01C865AD.59CFD740
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Increase by inches today
----------=_NextPart_000_0009_01C865AD.59CFD740
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.vdkvsdpe.com/">Increase by inches =
today</A></BODY></HTML>
----------=_NextPart_000_0009_01C865AD.59CFD740--


Received: from host96-85-static.43-88-b.business.telecomitalia.it (host96-85-static.43-88-b.business.telecomitalia.it [88.43.85.96]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11LQ6im051722 for <[e-mail]>; Fri, 1 Feb 2008 14:26:09 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000a01c86519$5b8e0140$60552b58@patrizio>
From: "Vic Malacarne" <[e-mail]>
To: [e-mail]
Subject: The end to all your frustration lies here - we have the solution to your woes.
Date: Fri, 1 Feb 2008 22:28:16 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0006_01C86521.BD526940"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0006_01C86521.BD526940
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Get a new huge colossal rod by clicking here.
----------=_NextPart_000_0006_01C86521.BD526940
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.lefoursm.com/">Get a new huge colossal rod by =
clicking=20
here.</A></BODY></HTML>
----------=_NextPart_000_0006_01C86521.BD526940--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m11BDL7X001381 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 1 Feb 2008 04:13:23 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m11BDL8e001380; Fri, 1 Feb 2008 04:13:21 -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.13.5/8.13.5) with ESMTP id m11BDGjS001369 for <[e-mail]>; Fri, 1 Feb 2008 04:13:19 -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 MAA22966; Fri, 1 Feb 2008 12:21:37 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008020112124022:70925 ; Fri, 1 Feb 2008 12:12:40 +0100 
Date: Fri, 1 Feb 2008 12:12:37 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Cc: "Stephen Kent" <[e-mail]>, "Stefan Santesson" <[e-mail]>, "[e-mail]" <[e-mail]>
Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 01/02/2008 12:12:40, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 01/02/2008 12:12:43, Serialize complete at 01/02/2008 12:12:43
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

A few comments.

(...)

>PKIX will pursue new work items in the PKI arena if working group 
>members express sufficient interest, and if approved by the cognizant 
>Security Area director. For example, certificate validation under X. 
>509 and PKIX standards calls for a relying party to use a trust 
>anchor as the start of a certificate path. 

This is not fully correct. Proposed change:

"For example, certificate validation under X. 509 and PKIX standards 
calls for a relying party to use *one or more* trust anchors and 
optional *additional conditions* as the start of a certificate path".

> Neither X.509 nor extant 
>PKIX standards define protocols for the management of trust anchors. 

This is untrue.

RFC 4210 "PKI Certificate Management Protocols" (CMP) defines data structures 
that allow to change a single trust anchor. The posting of these data structures 
which are certificates allow to change gracefully one trust anchor. These certificates 
may be placed in a directory and can be retrieved using any kind of protocol able 
to obtain ordinary certificates.

Page 9 :

      10. A graceful, scheduled change-over from one non-compromised CA
          key pair to the next (CA key update) must be supported (note
          that if the CA key is compromised, re-initialization must be
          performed for all entities in the domain of that CA). An end
          entity whose PSE contains the new CA public key (following a
          CA key update) must also be able to verify certificates
          verifiable using the old public key. End entities who directly
          trust the old CA key pair must also be able to verify
          certificates signed using the new CA private key.  (Required
          for situations where the old CA public key is "hardwired" into
          the end entity's cryptographic equipment).

Page 19:

4.4 Root CA key update

   This discussion only applies to CAs that are a root CA for some end
   entity.

   The basis of the procedure described here is that the CA protects its
   new public key using its previous private key and vice versa. Thus
   when a CA updates its key pair it must generate two extra
   cACertificate attribute values if certificates are made available
   using an X.500 directory (for a total of four:  OldWithOld;
   OldWithNew; NewWithOld; and NewWithNew).

   When a CA changes its key pair those entities who have acquired the
   old CA public key via "out-of-band" means are most affected. It is
   these end entities who will need access to the new CA public key
   protected with the old CA private key. However, they will only
   require this for a limited period (until they have acquired the new
   CA public key via the "out-of-band" mechanism). This will typically
   be easily achieved when these end entities' certificates expire.

   The data structure used to protect the new and old CA public keys is
   a standard certificate (which may also contain extensions). There are
   no new data structures required.

Proposed change:

"PKIX standards define protocols for the management of a single trust anchor, 
but not for the management of several trust anchors trusted under a single 
validation policy.

ETSI defines signature policies formats in "ETSI TR 102 272 V1.1.1 (2003-12)
ASN.1 format for signature policies".  ETSI also defines signature policies formats 
in "ETSI TR 102 038 V1.1.1 (2002-04) XML format for signature policies

Validation policies are superset of signature policies, but there exists no standard 
to manage validation policies".

>Existing mechanisms for managing trust anchors, e.g., in browsers, 
>are limited in functionality and non-standard. There is considerable 
>interest in the PKI community to define a standard model for trust 
>anchor management, and standard protocols to allow remote management. 
>Thus a future work item for PKIX is the definition of such protocols 
>and associated data models.

Proposed change:

"Existing mechanisms for managing trust anchors, e.g., in browsers, 
are limited in functionality and non-standard. There is considerable 
interest in the PKI community to define standard data structures and 
protocols to allow remote management of validation policies. 
Thus a future work item for PKIX is the definition of such data structures, 
protocols and associated data models".

>UPDATED PKIX Milestones

>Feb 2008 Update to CMC approved as PROPOSED Standard
>Mar 2008 RFC 3280bis approved as PROPOSED Standard
>Mar 2008 ECC Algorithms approved as PROPOSED Standard
>Mar 2008 TAM Problem Statement published as Informational
 October  2008 TAM Problem Statement published as Informational
>Jul 2008 TAM Protocols and Models published as PROPOSED Standard
 April  2009 TAM data structures and protocols as PROPOSED Standard

Denis

PS 1 : ETSI TSs and TRs are available free of charge at:
http://www.etsi.org/WebSite/Standards/StandardsDownload.aspx

PS 2: Validation policies are defined in RFC 3379 and used in RFC 5055 (SCVP).






Received: from [88.128.38.129] (tmo-095-224.customers.d1-online.com [80.187.95.224]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TIHpOu078261 for <[e-mail]>; Fri, 29 Feb 2008 11:17:54 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c87aff$5946cb00$81268058@Daniel>
From: "Ilpo mohammed" <[e-mail]>
To: [e-mail]
Subject: Don't wait, add inches today
Date: Fri, 29 Feb 2008 19:17:31 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C87B07.BB0B3300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0003_01C87B07.BB0B3300
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

This 2008, make sure you are ready to rock and pleasure all the women
----------=_NextPart_000_0003_01C87B07.BB0B3300
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.limigatur.com/">This 2008, make sure you are ready =
to rock=20
and pleasure all the women</A></BODY></HTML>
----------=_NextPart_000_0003_01C87B07.BB0B3300--


Received: from 29-158-177-194-adsl.net4you.net (29-158-177-194-adsl.net4you.net [194.177.158.29]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1TCG3Zj040329 for <[e-mail]>; Fri, 29 Feb 2008 05:16:05 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c87acc$d795e0a0$1d9eb1c2@pcwinkler>
From: "Braden creighton" <[e-mail]>
To: [e-mail]
Subject: Intimate bedroom secrets here!
Date: Fri, 29 Feb 2008 13:15:58 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C87AD5.395A48A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0009_01C87AD5.395A48A0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

increase the volume of your cum and the size of your pipe today.
----------=_NextPart_000_0009_01C87AD5.395A48A0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.polifeainv.com/">increase the volume of your cum =
and the=20
size of your pipe today.</A></BODY></HTML>
----------=_NextPart_000_0009_01C87AD5.395A48A0--


Received: from annrabson.com ([81.90.214.21]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1TA7C8j027519; Fri, 29 Feb 2008 03:07:15 -0700 (MST) (envelope-from [e-mail])
Received: from Buhgalter [77.207.137.109] (port=11356 helo=Buhgalter) by 15d65a51annrabson.com with ESMTP id v4HAYSOL506531 for <[e-mail]>; Fri, 29 Feb 2008 15:02:13 +0500
Message-ID: <001201c87ae4$10de85d0$01bffb5c@Buhgalter>
From: adam <[e-mail]>
To: [e-mail]
Subject: On be trivial
Date: Fri, 29 Feb 2008 15:02:13 +0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C87AE4.10DE85D0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2720.1106
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2720.1081

This is a multi-part message in MIME format.

------=_NextPart_000_000F_01C87AE4.10DE85D0
Content-Type: text/plain;
	charset="windows-1250"
Content-Transfer-Encoding: quoted-printable


there is a great deal of money at stake and the question is who
from your very eyes. Of course this, so call PROGRESS doesn't
information-processing systems and computers remains extensive. =


------=_NextPart_000_000F_01C87AE4.10DE85D0
Content-Type: text/html;
	charset="windows-1250"
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=3Dwindows-125=
0">
<META content=3D"MSHTML 6.00.2720.3000" name=3DGENERATOR>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV>what I believe in and all of a sudden I feel strange about doing</DIV>=
<BR>
<P><DIV>C A 0N A D/7AN &nbsp;&nbsp;&nbsp; P 7 9H A RM A 3CY </DIV></P>
<DIV>RA-VI-AG - $1.44 </DIV>
<DIV>C 4/ A L / S - $2.26</DIV>
<DIV>S9 O M A - $0.69</DIV>
<DIV>L E7 V / T R A - $3.64</DIV>
<DIV>F E _MALE AG-RA-VI - $1.53</DIV>
<DIV>U 8 L T 1R A M - $1.32</DIV>
<DIV>159  Items on S /AL \E Today.</DIV>
<P><DIV><A href=3D"http://geocities.com/sandychristian44"><b><font size=3D4=
>No overhead - lowest price</font></b></A></DIV></P>
<DIV>expression will be depends on the the designer. If the designer</DIV>

</BODY></HTML>

------=_NextPart_000_000F_01C87AE4.10DE85D0--



Received: from administrador.dinanet.net.co ([200.89.226.186]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1T3uUUR098843; Thu, 28 Feb 2008 20:56:30 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost.localdomain [127.0.0.1]) by host76914804.metromix.com (8.13.1/8.13.1) with SMTP id 56JYuSF272.442037.608.3zM.8295626908496 for <[e-mail]>; Thu, 28 Feb 2008 21:55:43 +0600
Message-ID: 23ef401c87a86$fd216650$bae259c8@administrador
From: "Delmar Brennan" <[e-mail]>
To: <[e-mail]>
Subject: Sw|ss R0lex made by top designers
Date: Thu, 28 Feb 2008 21:55:43 +0600
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

Now we admire to offer you New Watches collection.

* Cheap prices

* Huge choice
(R0lex,Bv|gari,Cartier,L0ngines,0mega,Patek.Philippe etc)

* Worldwide shipping 

* Excellent quality

Today you have amazing possibility to save huge sum of money.

P.S. 15% off if you order 2 or more items.

http://www.bezelopscheap.com



Received: from 22.25.broadband6.iol.cz (22.25.broadband6.iol.cz [88.101.25.22]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SJ6xPD055923 for <[e-mail]>; Thu, 28 Feb 2008 12:07:00 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000c01c87a3d$15a83cc0$16196558@work>
From: "Yihua iron" <[e-mail]>
To: [e-mail]
Subject: Intimate bedroom secrets here!
Date: Thu, 28 Feb 2008 20:06:55 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C87A45.776CA4C0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0008_01C87A45.776CA4C0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Don't let people discourage you because you're tiny - here's a solution =
to permanant, fast gains.
----------=_NextPart_000_0008_01C87A45.776CA4C0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.saupaloed.com/">Don't let people discourage you =
because=20
you're tiny - here's a solution to permanant, fast =
gains.</A></BODY></HTML>
----------=_NextPart_000_0008_01C87A45.776CA4C0--


Received: from [190.53.79.142] ([190.53.79.142]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1SBCIdv004509 for <[e-mail]>; Thu, 28 Feb 2008 04:12:22 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000d01c879fa$c6b5fea0$8e4f35be@ANJUPPEH2>
From: "efioejf mummert" <[e-mail]>
To: [e-mail]
Subject: Love is possible now.
Date: Thu, 28 Feb 2008 05:12:16 -0600
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0009_01C879C8.7C1B8EA0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080227-0, 27/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0009_01C879C8.7C1B8EA0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Don't forget this one simple rule of lovemaking: SIZE MATTERS.
----------=_NextPart_000_0009_01C879C8.7C1B8EA0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.nimeisa.com/">Don't forget this one simple rule of =

lovemaking: SIZE MATTERS.</A></BODY></HTML>
----------=_NextPart_000_0009_01C879C8.7C1B8EA0--


Received: from enternet.hu (88.4.81.117.broad.sz.js.dynamic.163data.com.cn [117.81.4.88] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1R9LIDO055689 for <[e-mail]>; Wed, 27 Feb 2008 02:21:22 -0700 (MST) (envelope-from [e-mail])
Received: from 208.11.75.2 (HELO mail.rollernet.us) by imc.org with ESMTP (DVSAEHJPLUYZ WPCLSK) id QpvgBU-sENVGv-Ng for [e-mail]; Wed, 27 Feb 2008 17:21:30 +0800
Message-ID: <102df01c87922$22eaeed0$c0a80103@Eugene>
From: "Eugene Scott" <[e-mail]>
To: "Jesus Green" <[e-mail]>
Subject: The 10 Best Things to Tell a Naked Woman
Date: Wed, 27 Feb 2008 17:21:30 +0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_66269_10347_01C87965.310E2ED0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1158
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1158

This is a multi-part message in MIME format.

------=_NextPart_66269_10347_01C87965.310E2ED0
Content-Type: text/plain;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Imagine being huge, thick and long even when flaccid!
http://juggerpaut.com/
------=_NextPart_66269_10347_01C87965.310E2ED0
Content-Type: text/html;
        charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3DWindows-1=
252">
<META content=3D"MSHTML 6=2E00=2E2800=2E1158" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff><DIV><FONT face=3DArial size=3D2>
<A href=3D"http://juggerpaut.com/">
Imagine being huge, thick and long even when flaccid!</A></FONT></DIV></B=
ODY></HTML>

------=_NextPart_66269_10347_01C87965.310E2ED0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1R1KqFk019125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 26 Feb 2008 18:20:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1R1Kqf8019124; Tue, 26 Feb 2008 18:20:52 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1R1KoQY019115 for <[e-mail]>; Tue, 26 Feb 2008 18:20:51 -0700 (MST) (envelope-from [e-mail])
Received: from philippslaptop.lan M2487P013.adsl.highway.telekom.at  (authenticated user [e-mail]) by mailbox.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 50-md50000000175.tmp for <[e-mail]>; Wed, 27 Feb 2008 02:20:47 +0100
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: Eric Norman <[e-mail]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Date: Wed, 27 Feb 2008 02:20:44 +0100
User-Agent: KMail/1.9.1
Cc: [e-mail]
References: <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <[e-mail]>
X-Authenticated-Sender: [e-mail]
X-Spam-Processed: mailbox.go-now.at, Wed, 27 Feb 2008 02:20:47 +0100 (not processed: spam filter disabled)
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1R1KpQY019118
Sender: [e-mail]
Precedence: 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,

> >  As Philipp says, a standard would need to specify how subdomain
> > matching is performed: does "*.bar.com" match "bar.com" or not?
>
> Similarly, does "*.wisc.edu" match "info.doit.wisc.edu"? 

Ok, perhaps some feedback from the certificate issueing practice helps:

Most of the certificates I saw from our users are the following way:

CN=wisc.edu
SAN=*.wisc.edu
SAN=wisc.edu

Since some browsers do not match *.wisc.edu as wisc.edu, the conservative 
method for issueing a certificate to ensure that it works is to include both 
*.wisc.edu and wisc.edu.
(And to ensure that it also works with applications that haven´t heard about 
SAN yet, and still use the CommonName, they usually include one hostname in 
the CommonName that is also contained in the SAN)

>From the regular expression methodology, the correct way would be that 
*.wisc.edu does not match wisc.edu

Con: The main application for multiple hostnames in my opinion is  
www.domain.com and domain.com, having a webserver respond to both 
http://www.domain.com/ and http://domain.com/ so that it also works in all 
browsers when people forget to write the www. in front.

smaller certificates. that only contain *.wisc.edu, but bytes are cheap 
nowadays, so who cares if the certificates are a kilobyte larger or not. (I 
haven´t had any customers who complained that their certificates are too 
large yet)

I don´t remember having seen someone with *.*.wisc.edu certificates yet.
Either they calculate with enough browsers supporting *.wisc.edu to match 
info.doit.wisc.edu, or they don´t need it to match that. (I guess that it´s 
not needed that often)

>From the security perspective, I think it would be bad if *.bar.com would 
match www.bankofamerica.com.bar.com unexpectedly.

So from my perspective, I think we don´t need *.wisc.edu to match wisc.edu or 
www.sub.wisc.edu, and we could live with a standard that says that it must 
not match anything else. Has anyone seen any applications where matching 
www.sub.wisc.edu or wisc.edu would be needed?

> At one
> time in the past, any maybe still, whether it did or not depended on
> which browser was being used.

Yes, that´s still the case.

Best regards,
Philipp Gühring




Received: from dsl-171-72.diodos-gsrt-gr.duth.gr (dsl-171-72.diodos-gsrt-gr.duth.gr [83.212.171.72]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1QF6Buo062914 for <[e-mail]>; Tue, 26 Feb 2008 08:06:12 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001201c87889$19a67090$48abd453@c32fd53da0be4f4>
From: "DaeHee Sacks" <[e-mail]>
To: [e-mail]
Subject: Achieve blessed happiness tonight and every night.
Date: Tue, 26 Feb 2008 17:06:01 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000E_01C87899.DD2F4090"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000E_01C87899.DD2F4090
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My friends just don't measure up to me, since i am a full 9 inches.
----------=_NextPart_000_000E_01C87899.DD2F4090
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.Thrieytoons.com/">My friends just don't measure up =
to me,=20
since i am a full 9 inches.</A></BODY></HTML>
----------=_NextPart_000_000E_01C87899.DD2F4090--


Received: from host170-238-static.61-82-b.business.telecomitalia.it (host170-238-static.61-82-b.business.telecomitalia.it [82.61.238.170]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1QC5ISZ044464 for <[e-mail]>; Tue, 26 Feb 2008 05:05:25 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000c01c8786e$d63f0890$aaee3d52@SIMONEPC>
From: "Florea Myumyun" <[e-mail]>
To: [e-mail]
Subject: Achieve blessed happiness tonight and every night.
Date: Tue, 26 Feb 2008 12:58:01 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0008_01C87877.38037090"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0008_01C87877.38037090
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

My friends just don't measure up to me, since i am a full 9 inches.
----------=_NextPart_000_0008_01C87877.38037090
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.Pliwoonel.com/">My friends just don't measure up =
to me,=20
since i am a full 9 inches.</A></BODY></HTML>
----------=_NextPart_000_0008_01C87877.38037090--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PMB3Ga071049 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 15:11:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1PMB3iA071048; Mon, 25 Feb 2008 15:11:03 -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.13.5/8.13.5) with SMTP id m1PMAtpF071010 for <[e-mail]>; Mon, 25 Feb 2008 15:10:56 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 7093 invoked by uid 0); 25 Feb 2008 22:10:37 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 25 Feb 2008 22:10:37 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Mon, 25 Feb 2008 16:59:04 -0500
To: "Denis Pinkas" <[e-mail]>, [e-mail]
From: Russ Housley <[e-mail]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
In-Reply-To: <[e-mail]>
References: <[e-mail]>
Mime-Version: 1.0
Content-Type: text/html; charset="iso-8859-1"
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>

<html>
<body>
Denis:<br><br>
The list of classifications can be augmented by the policy that is
specified.&nbsp; This is very clear in RFC 3281, which says:<br><br>
&nbsp;&nbsp; An organization can develop its own security policy that
defines<br>
&nbsp;&nbsp; security classification values and their meanings.&nbsp;
However, the BIT<br>
&nbsp;&nbsp; STRING positions 0 through 5 are reserved for the basic
security<br>
&nbsp;&nbsp; classification hierarchy.<br><br>
If you have an access control policy that requires something other than
classification and categories, then this data structure is not going to
work for you.&nbsp; Fine.&nbsp; Do not try to changes this
structure.&nbsp; Instead define a different one with a different name and
object identifier.&nbsp; This one seems to be working for many
organizations.&nbsp; Please do not mess with it.<br><br>
Russ<br><br>
<br>
At 09:49 AM 2/25/2008, Denis Pinkas wrote:<br>
<blockquote type=cite class=cite cite="">There are one additional issue
not mentioned below:<br>
&nbsp;<br>
5 - Should we copy and paste the definition of clearance made in RFC 3281
?<br>
&nbsp;<br>
Although many people support that opinion, there has been objections to
do it, <br>
since this definition does not allow to support security sensitivities
independently of the security category.<br>
&nbsp;<br>
This does not reflect real world situations where, given one policyId,
there will be different <br>
securityCategories, each one with a different sensitivity (which is a
much better word than &quot;class&quot;).<br>
In addition, the classList definition is incorrect for the two first bits
and does not even support <br>
the example from section 1: HIGHLY CONFIDENTIAL and GENERAL <br>
(called &quot;security classification values&quot;, which is not an
adequate terminology).<br>
&nbsp;<br>
Another argument is interoperability: the current definition of
SecurityCategory is too open <br>
to allow for interoperability. The draft does not allow to implement
interoperable solutions. <br>
&nbsp;<br>
Denis<br>
&nbsp;<br>
<hr>
<font face="Courier, Courier">Folks,<br><br>
I've been observing this discussion and want to take this opportunity to
summarize what I see as the major issues that have been raised, provide
my perspective on them, and suggest ways to resolve them.<br><br>
1. Should we put authorization data of this sort in a PKC vs. an
AC?<br><br>
ACs were designed to convey authorization data, but PKIX has not
prohibited carrying such data in PKCs. For example, RFC 3779 does so for
IP address and AS number ranges. Since there are precedents&nbsp; in
Internet standards for carriage of authorization data in PKCs this
argument need not be revisited.<br><br>
2. If we carry this data in a PKC, should it be in the SDA extension or
be a separate extension?<br><br>
Although this is provision for carrying clearance data in the SDA
extension, there is an argument for carrying it in a separate extension.
In some instances (including the ones motivating this I-D) the clearance
data may be processed by high assurance devices/software. In such cases
one can argue that having an extension that carries only this data makes
such high assurance processing easier. One might also argue that in such
contexts one would mark this extension as critical. RFC 3280bis says the
SDA extension is always non-critical, which also argues for creating a
separate extension. I assume that most folks agree that the CA clearance
constraints would be a new extension, a critical one. If the two sets of
data are to be processed together in the contexts alluded to above, it
seems to make sense that both be new extensions. A newly assigned OID for
a new extension seems appropriate to me. I'd like to better the
motivation to reuse the directory attribute OID here,<br><br>
3. It's not clear that there is a need to put the CA constraints
extension in a self-signed certificate, but it also is not clearly wrong.
I can imagine contexts In which it makes sense to require that the data
from this extension be present in a certificate path for certificate
processing. That seems to allow three options: have a self-signed
certificate representing a TA contain the extension, have a TA issue a
certificate with the extension but not imbed it in the TA's self-signed
certificate, or note that this is an example of &quot;associated
data&quot; for a TA and is used to initialize the certificate path
validation algorithm (as extended to accommodate this data).<br><br>
RFC 3779 adopted the first option when it discussed the need to bind the
address space and/or AS number data to a trust anchor. It states that a
certificate serving as a trust anchor MUST contain the extensions that
will be used to constrain instances of the extension in subsequent
certificates in the path. So we have a precedent for option #1. However,
given our ongoing efforts to more formally specify the notion associated
data for a TA, it makes sense to consider the third option as well. I'd
like to hear arguments about the merits (and demerits) of all three
options, given<br><br>
<br>
4. Stefan raised two concerns about putting clearance info in a
certificate at all. Although he didn't say it precisely this way, I note
that it is usually the case that the authorization of an individual to
access classified data depends not only on the individual's clearance,
but also on the (accreditation of the) machine being used to access the
data, and on the location that machine (if it is portable). In my
experience it is not appropriate to say that an individual's clearance
changes based on the system he is using, but rather that an individual's
authorization usually is constrained by the system he is using. I raised
a similar issue with a earlier draft, noting that when a certificate with
clearance data is issued to a machine, vs. a person, it is not really an
expression of clearance, but of accreditation. The text I the draft needs
to accurately reflect this subtle distinction. Stefan also noted that the
requisite path validation algorithm extensions are non-trivial. If the
authors want to qualify the intended contexts in which it is expected
that the newly proposed pair of extensions will be used, that might
mitigate this concern. The authors need to address these issues in the
text.<br>
</font><font face="Courier, Courier" size=5><br>
<hr>
</font></blockquote></body>
</html>



Received: from [82.141.171.109] ([82.141.171.109]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PIhPT1052998 for <[e-mail]>; Mon, 25 Feb 2008 11:43:27 -0700 (MST) (envelope-from [e-mail])
Message-ID: <001101c877de$50a0a710$6dab8d52@cofe0c034ed170>
From: "Edna asdas" <[e-mail]>
To: [e-mail]
Subject: Free the inner potential in you.
Date: Mon, 25 Feb 2008 19:43:29 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_000D_01C877E6.B2650F10"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_000D_01C877E6.B2650F10
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Make hay while the sun shines, a mighty rod make girls mine.
----------=_NextPart_000_000D_01C877E6.B2650F10
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.pokiter.com/">Make hay while the sun shines, a =
mighty rod=20
make girls mine.</A></BODY></HTML>
----------=_NextPart_000_000D_01C877E6.B2650F10--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PFc8bN036558 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 08:38:08 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1PFc8gT036557; Mon, 25 Feb 2008 08:38:08 -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.13.5/8.13.5) with ESMTP id m1PFc6Lc036550 for <[e-mail]>; Mon, 25 Feb 2008 08:38:07 -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 QAA62424 for <[e-mail]>; Mon, 25 Feb 2008 16:47:21 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008022516373418:169328 ; Mon, 25 Feb 2008 16:37:34 +0100 
Date: Mon, 25 Feb 2008 16:37:32 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2008 16:37:34, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2008 16:38:06, Serialize complete at 25/02/2008 16:38:06
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl,

Comments are in line.

>comments inline... 

><snip>
>
>We both agree that specifying the format is the major goal. 
>However the current text does not say it yet.
>
>The concept of TA is defined in RFC 3280 and since 3280bis will be soon
>issued, it will not be changed before many years.
>
>[CRW] The current draft requires compatibility with RFC3280.  
>
>It is not possible to use the same name, i.e. TA, with two different
>meanings.
>
>So you should use a different name for a "TA with associated data".
>For the time being let us call it TAAD.   

>[CRW] I don't see the need for this distinction.  There have been two TA
>structures posted so far (the definitions in 3125 and TAMP).  Both are
>similar and could be viewed as a "TA with associated data".  RFC3280bis
>does not include the inputs to path validation in its TA definition, so
>that information would be associated data.  

[DP] I am puzzled. On one hand you say the two concepts are different and 
on the other hand you say "I don't see the need for this distinction". 

In order to understand eachother, we need to speak using the same words 
for the same concepts. At this time, we have not yet acheived that goal.

>A TA Store is not simply an addition of TAADs. 
>Some additional data may apply for all TAADs present in given TAS (TA
>Store).
>Let us call it for the time being: TASAD.
>
>The content of a TAS may then be modelized as: TASAD + sigma (TAAD)
>
>With this model in mind, I would agree that it is possible to add or
>remove a TAAD as a whole.
>
>We will have to identify what kind of data can be associated with a TAS
>and what kind of data can be associated with a TA. 
>
>Do you agree with the above concepts
>(leaving aside the terminology that can be changed) ? 
>
>[CRW] The idea of TA store data independent of TA data is interesting
>and ought to be considered.

[DP] Thanks. There are however further ideas there. So I restate my question:
     Do you agree with the above concepts
     (leaving aside the terminology that can be changed) ?

><snip>
>
>Would you be able to elaborate, or provide an example for pull ?
>
>[CRW] The language in the 2nd paragraph of section 3 aims to support the
>generation of a TA mgmt message that is targeted such that unintended
>trust anchor stores reject the message.  Whether the message is pushed
>or pulled doesn't matter.  For example, if I generate a TA mgmt message
>that targets one TA store to add a TA and try to use that message to add
>the TA to a different trust store then the operation should fail.

[DP] Undertstood, but this may lead to a large number of ways to do it, 
whether a TA Store simply has a unique name, belongs to a category or 
has a key of its own. Interoperability might be very difficult for that 
requirement. So I would rather consider it as an option.
 
><snip>

Denis





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PFaHYU036385 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 08:36:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1PFaH1i036384; Mon, 25 Feb 2008 08:36:17 -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.13.5/8.13.5) with ESMTP id m1PFaB1S036361 for <[e-mail]>; Mon, 25 Feb 2008 08:36: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 QAA34510 for <[e-mail]>; Mon, 25 Feb 2008 16:45:25 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008022516360364:169276 ; Mon, 25 Feb 2008 16:36:03 +0100 
Date: Mon, 25 Feb 2008 16:36:01 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re:  I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2008 16:36:03, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2008 16:36:11, Serialize complete at 25/02/2008 16:36:11
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Carl,

Some additional comments on this e-mail.
Comments are in line too.

>Comments inline...
>
><snip>
>This draft redefines "trust anchors" in a way that is not compatible
>with RFC 3280. RFC 3280 does not contain a formal definition of a trust
>anchor, but contains the following sentences:
>
>The trust anchor information includes:
>
>   (1)  the trusted issuer name,
>
>   (2)  the trusted public key algorithm,
>
>   (3)  the trusted public key, and
>
>   (4)  optionally, the trusted public key parameters associated
>        with the public key.
>
>It also states:
>
>   Valid paths begin with certificates issued by a trust anchor.
>   The algorithm requires the public key of the CA, the CA's name, 
>   and any constraints upon the set of paths that may be validated 
>   using this key.
>
>This draft states:
>
>   Trust Anchor: A trust anchor is an authoritative entity represented
>   via a public key and associated data. (...) 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 makes a big difference. 
>
>In this draft, the trust anchor would include "constraints expressed in
>the associated data for the trust anchor", whereas RFC 3280 considers
>that these constraints are external to the trust anchor information.
>
>[CRW] This difference is intentional, as RFC3280 is only one context
>addressed for TA mgmt.    

[DP] You recognize that there is a difference, but you still want 
to use the same wording. Once again, two different wordings should be used.

><snip>
>
>Let us start from the beginning: an application needs to validate some
>public key certificates and for doing this will have to use data
>contained in at least one Trust Anchor Store which contains one or more
>sets of trust anchor *and additional data*.
>
>[CRW] A more general starting point would be signature verification,
>since validating public key certificates is only one example.

[DP] No. Signature verification is more complex.

>A "Trust Anchor Store manager" (that is different from the notion of "TA
>manager" as defined in the draft) may need to change or update the
>content of a given Trust Anchor Store. 
>
>[CRW] Perhaps the "TA Manager" definition in the draft should be "TA
>Store Manager" since they are referring to the same role.

[DP] The roles are different, but I would be happy if you drop the term "TA manager". 

>The content of a Trust Anchor Store equals to a validation policy. 
>Validation policies may be rather complex, so the very first requirement
>is to be able to define or change the content of a Trust Anchor Store
>*as a whole*.

>[CRW] I could see this either way but replacing an entire store to
>change one bit in one TA may be too inefficient in some scenarios.
>Maybe there's an additional requirement to support whole store
>replacement, but that doesn't seem appropriate as the only mechanism.

What you use a signature policy, you cannot updrade or downgrade it, 
you must replace it as a whole and assign it a new OID or URN.

>It is very doubtful that *updates* to a Trust Anchor Store would be
>feasible. 
>The current draft makes the assumption that it would. 

>[CRW] Why is this so?  Current means don't require replacing an entire
>store to add or remove a single TA.

[DP] This would only be feasible for the use with an authentication service.

When you have a signature policy, you must keep track of the conditions 
that were used and thus a signature policy cannot be modified.

When you have a confidentiality policy, it may be important to know 
what were the rules when a document was encrypted. In the same way, 
these policies may need to be archived.

>So I am challenging the fact that the following requirement should
>apply:
>
>    At a minimum, it [a general-purpose solution] must enable 
>    a trust anchor manager to discovery which TA stores are present, 
>    to add trust anchors to, remove trust anchors from, and determine 
>    which trust anchors are installed in a particular trust anchor
>    store.

>A Trust Anchor Store manager may need to change data in the Trust Anchor
>Store that is not associated with one TA itself. For example, it may
>decide that OCSP responses shall be used, or that CRLs shall be used, or
>that a new CRL shall be fetched if a CRL in the cache is older that 2
>hours, or that delta-CRLs shall be used, etc ... This requirement may be
>different for every level of the certification tree or in the
>certification forest. 
>This kind of requirement is fully missing in the current draft.
>
>[CRW] Revocation sources could be an additional form of constraint.
>That seems reasonable.

[DP] Fine.

>Whatever the certification tree is, a Trust Anchor Store manager may
>also decide to use leaf certificates that contain a particular
>extension, e.g.
>which mentions that it is a qualified certificate. This kind of concept
>is a property associated data contained in a Trust Anchor Store.
>
>[CRW] OK.
>
>The draft considers that each trust anchor is associated with a "scope
>of authority" "(e.g., a trust anchor public key may be limited to
>verification of firmware updates only), or more general (such as to
>validate certification paths for certificates issued to users or
>devices)", whereas the picture is fully inversed: a given "scope of
>authority" will accept one or more trust anchors *and additional data*.
>
>So I am challenging the fact that the following requirement should
>apply:
>
> Trust anchors may be explicitly authorized for a limited set of
>purposes.
>
>The major problem with this draft is that it places Trust Anchors at the
>top of the hierarchy, whereas Trust Anchor Stores are at the top. 
>
>[CRW] This relates to a discussion on the TAM list regarding requiring
>different trust anchor store managers with different privileges to
>manage different trust anchor stores.  Addressing that requirement may
>solve the hierarchy problem you are citing.

[DP] I am unsure it would, unless the concept of "TA manager" vanishes. 

>Using the vocabulary defined in RFC 5055, each Trust Anchor Store
>contains one "validation policy".
>
>This means that it is the responsibility of the Trust Anchor Store
>manager to define which trust anchors shall be used and which additional
>data shall be associated with it.
>
>The current draft is mandating the existence of a *single* protocol to
>"push" 
>information to the Trust Anchor Stores. It is much more important to
>specify the format of the information that will be pushed and to leave
>the details for pushing it to the local OS or to a management
>application.
>
>[CRW] Specifying the format is the goal.  The draft mandates neither
>push nor pull.

[DP] I am glad that you agree "Specifying the format is the goal". 
The draft should be modified to acknowledge it.

>The content of a Trust Anchor Store should be formatted while being
>transferred, so that it can be locally interpreted without any
>ambiguity. 
>
>This allows pulling the formatted data.
>
>[CRW] Agree.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   A protocol for TA management must allow a TA management 
>   transaction, to be directed to all TA stores for which the manager 
>   is responsible, targeted to an enumerated list of one or more
>   groups of trust anchor stores, or targeted to an individual trust
>   anchor store. 
>
>[CRW] This requirement does not relate to push or pull.  The language
>should be improved to indicate the intent is to limit the intended
>recipients (i.e., target trust stores).

>"Discovering which trust anchors installed in a particular trust anchor
>store" is not an interesting requirement. Knowing that a given store contains
>four trust anchors does not help, since the additional data that places
>constraints both on the way to build the certification tree and *the way
>to check that none of the certificates from the certification tree is
>revoked* are not part of the information placed in a trust anchor.
>
>[CRW] TAs are defined as including the additional data (see your earlier
>objection).  Including revocation mechanism as a constraint seems fine
>to me.  

[DP] Fine.

>So I am challenging the fact that the following requirement should
>apply:
>
>   Despite the prevalent use of trust anchors, there is neither a
>   standard means for discovering which trust anchors installed in a
>   particular trust anchor store nor a standard means of managing those
>   trust anchors.
>
>The current draft is mandating the existence of a *single* protocol to
>"pull" information from Trust Anchor Stores. It is more important to specify
>the format of the information that will be pulled and to leave the
>details for pulling it from the local OS or from a management
>application.
>
>[CRW] Specifying the format is the goal.  The draft mandates neither
>push nor pull.
>
>So I am challenging the fact that the following requirement should
>apply:
>
>   A trust anchor manager must be able to authenticate which device
>   produced a report listing the contents of a trust anchor store and,
>   be able to confirm the contents of the report have not been
>   subsequently altered.
>
>The document states:
>
>   A trust anchor definition should enable the representation of
>   constraints that influence certification path validation or otherwise
>   establish the scope of usage of the trust anchor public key.
>
>There are two problems with that sentence:
>
> - a vocabulary problem, since the current trust anchor definition 
>   does not include the constraints, and
>
>[CRW] The trust anchor definition in the draft does include the
>constraints.

[DP] In this case the draft is not consistent because it does 
at some point of time and at some other it does not.
In addition, your reply does not address the concern that is raised.

> - the fact that constraints that influence certification path
>   validation may be understood either as constraints that allow to 
>   builda certification path or also as constraints that allow to make 
>   sure that none of the certificates from the certification path are revoked
>
>   using some timeliness indicators.
>
>[CRW] I'm not sure what this means.

[DP] This point has been responded in an earlier e-mail.

     Denis

>Finally the security considerations section contains additional
>requirements (e.g. "it must be possible to authenticate the originator
>of a TA management transaction and confirm the authorization of the
>originator for that transaction", whereas it should only highlight some
>security issues.

>[CRW] This is going to be fixed.  The plan is to replace this draft with
>a requirements draft.  A problem statement isn't needed since this isn't
>a BOF.  We started to late to get a new -00 draft submitted before the
>deadline.
>
>RFC 3379 and RFC 5055 should be added to the informative references.
>
>[CRW] OK.
>
>Denis
>
>>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 Problem Statement
>>	Author(s)       : R. Reddy, C. Wallace
>>	Filename        :
>>  draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
>>	Pages           : 15
>>	Date            : 2008-02-18
>>
>>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 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 as well as problems that must be addressed by such a 
>>mechanism.  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-problem-sta
>>tement-01.txt
>>
>>To remove yourself from the I-D Announcement list, send a message to 
>>[e-mail] with the word unsubscribe in the body of 
>>the message.
>>You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
>>to change your subscription settings.
>>
>>Internet-Drafts are also available by anonymous FTP. Login with the 
>>username "anonymous" and a password of your e-mail address. After 
>>logging in, type "cd internet-drafts" and then
>>	"get draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>>
>>A list of Internet-Drafts directories can be found in 
>>http://www.ietf.org/shadow.html or 
>>ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>
>>Internet-Drafts can also be obtained by e-mail.
>>
>>Send a message to:
>>	[e-mail].
>>In the body type:
>>	"FILE
>/internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt".
>>
>>NOTE:   The mail server at ietf.org can return the document in
>>	MIME-encoded form by using the "mpack" utility.  To use this
>>	feature, insert the command "ENCODING mime" before the "FILE"
>>	command.  To decode the response(s), you will need "munpack" or
>>	a MIME-compliant mail reader.  Different MIME-compliant mail
>readers
>>	exhibit different behavior, especially when dealing with
>>	"multipart" MIME messages (i.e. documents which have been split
>>	up into multiple messages), so check your local documentation on
>>	how to manipulate these messages.
>>
>>Below is the data which will enable a MIME compliant mail reader 
>>implementation to automatically retrieve the ASCII version of the 
>>Internet-Draft.
>>
>>Content-Type: text/plain
>>Content-ID:     <[e-mail]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt






Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1PEncpn032477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 25 Feb 2008 07:49:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1PEncbF032476; Mon, 25 Feb 2008 07:49:38 -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.13.5/8.13.5) with ESMTP id m1PEnZ1M032467 for <[e-mail]>; Mon, 25 Feb 2008 07:49:36 -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 PAA88168 for <[e-mail]>; Mon, 25 Feb 2008 15:58:48 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008022515492950:167764 ; Mon, 25 Feb 2008 15:49:29 +0100 
Date: Mon, 25 Feb 2008 15:49:25 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2008 15:49:29, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 25/02/2008 15:49:34, Serialize complete at 25/02/2008 15:49:34
Message-ID: <[e-mail]>
Content-Type: multipart/alternative; boundary="=====003_Dragon332530125530_====="
Sender: [e-mail]
Precedence: 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.

--=====003_Dragon332530125530_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset="iso-8859-1"

There are one additional issue not mentioned below:

5 - Should we copy and paste the definition of clearance made in RFC 3281 ?

Although many people support that opinion, there has been objections to do it, 
since this definition does not allow to support security sensitivities independently of the security category.

This does not reflect real world situations where, given one policyId, there will be different 
securityCategories, each one with a different sensitivity (which is a much better word than "class").

In addition, the classList definition is incorrect for the two first bits and does not even support 
the example from section 1: HIGHLY CONFIDENTIAL and GENERAL 
(called "security classification values", which is not an adequate terminology).

Another argument is interoperability: the current definition of SecurityCategory is too open 
to allow for interoperability. The draft does not allow to implement interoperable solutions. 

Denis




Folks,

I've been observing this discussion and want to take this opportunity to summarize what I see as the major issues that have been raised, provide my perspective on them, and suggest ways to resolve them.

1. Should we put authorization data of this sort in a PKC vs. an AC?

ACs were designed to convey authorization data, but PKIX has not prohibited carrying such data in PKCs. For example, RFC 3779 does so for IP address and AS number ranges. Since there are precedents  in Internet standards for carriage of authorization data in PKCs this argument need not be revisited.

2. If we carry this data in a PKC, should it be in the SDA extension or be a separate extension?

Although this is provision for carrying clearance data in the SDA extension, there is an argument for carrying it in a separate extension. In some instances (including the ones motivating this I-D) the clearance data may be processed by high assurance devices/software. In such cases one can argue that having an extension that carries only this data makes such high assurance processing easier. One might also argue that in such contexts one would mark this extension as critical. RFC 3280bis says the SDA extension is always non-critical, which also argues for creating a separate extension. I assume that most folks agree that the CA clearance constraints would be a new extension, a critical one. If the two sets of data are to be processed together in the contexts alluded to above, it seems to make sense that both be new extensions. A newly assigned OID for a new extension seems appropriate to me. I'd like to better the motivation to reuse the directory attribute OID here,

3. It's not clear that there is a need to put the CA constraints extension in a self-signed certificate, but it also is not clearly wrong. I can imagine contexts In which it makes sense to require that the data from this extension be present in a certificate path for certificate processing. That seems to allow three options: have a self-signed certificate representing a TA contain the extension, have a TA issue a certificate with the extension but not imbed it in the TA's self-signed certificate, or note that this is an example of "associated data" for a TA and is used to initialize the certificate path validation algorithm (as extended to accommodate this data).

RFC 3779 adopted the first option when it discussed the need to bind the address space and/or AS number data to a trust anchor. It states that a certificate serving as a trust anchor MUST contain the extensions that will be used to constrain instances of the extension in subsequent certificates in the path. So we have a precedent for option #1. However, given our ongoing efforts to more formally specify the notion associated data for a TA, it makes sense to consider the third option as well. I'd like to hear arguments about the merits (and demerits) of all three options, given


4. Stefan raised two concerns about putting clearance info in a certificate at all. Although he didn't say it precisely this way, I note that it is usually the case that the authorization of an individual to access classified data depends not only on the individual's clearance, but also on the (accreditation of the) machine being used to access the data, and on the location that machine (if it is portable). In my experience it is not appropriate to say that an individual's clearance changes based on the system he is using, but rather that an individual's authorization usually is constrained by the system he is using. I raised a similar issue with a earlier draft, noting that when a certificate with clearance data is issued to a machine, vs. a person, it is not really an expression of clearance, but of accreditation. The text I the draft needs to accurately reflect this subtle distinction. Stefan also noted that the requisite path validation algorithm extensions are non-trivial!
. If the authors want to qualify the intended contexts in which it is expected that the newly proposed pair of extensions will be used, that might mitigate this concern. The authors need to address these issues in the text.

--=====003_Dragon332530125530_=====
Content-Transfer-Encoding: 7bit
Content-Type: text/html;
	charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content="MSHTML 6.00.2800.1601" name=GENERATOR></HEAD>
<BODY>
<DIV>There are one additional issue not mentioned below:</DIV>
<DIV>&nbsp;</DIV>
<DIV>5 - Should we copy and paste the definition of clearance made in RFC 3281 
?</DIV>
<DIV>&nbsp;</DIV>
<DIV>Although many people support that opinion, there has been objections to do 
it, <BR>since this definition does not allow to support security sensitivities 
independently of the security&nbsp;category.</DIV>
<DIV>&nbsp;</DIV>
<DIV>This does not reflect real world situations where, given one policyId, 
there will be different <BR>securityCategories, each one with a different 
sensitivity (which is a much better word than "class").<BR></DIV>
<DIV>In addition,&nbsp;the classList definition is incorrect for the two first 
bits and does not even support <BR>the example from section 1: HIGHLY 
CONFIDENTIAL and GENERAL <BR>(called "security classification values", which is 
not an adequate terminology).</DIV>
<DIV>&nbsp;</DIV>
<DIV>Another argument is interoperability: the current definition of 
SecurityCategory is too open <BR>to allow for interoperability. The draft does 
not allow to implement interoperable solutions. </DIV>
<DIV>&nbsp;</DIV>
<DIV>Denis</DIV>
<DIV>&nbsp;</DIV>
<DIV>
<HR>
</DIV>
<DIV><FONT face=Courier color=#000000>Folks,<BR><BR>I've been observing this 
discussion and want to take this opportunity to summarize what I see as the 
major issues that have been raised, provide my perspective on them, and suggest 
ways to resolve them.<BR><BR>1. Should we put authorization data of this sort in 
a PKC vs. an AC?<BR><BR>ACs were designed to convey authorization data, but PKIX 
has not prohibited carrying such data in PKCs. For example, RFC 3779 does so for 
IP address and AS number ranges. Since there are precedents&nbsp; in Internet 
standards for carriage of authorization data in PKCs this argument need not be 
revisited.<BR><BR>2. If we carry this data in a PKC, should it be in the SDA 
extension or be a separate extension?<BR><BR>Although this is provision for 
carrying clearance data in the SDA extension, there is an argument for carrying 
it in a separate extension. In some instances (including the ones motivating 
this I-D) the clearance data may be processed by high assurance 
devices/software. In such cases one can argue that having an extension that 
carries only this data makes such high assurance processing easier. One might 
also argue that in such contexts one would mark this extension as critical. RFC 
3280bis says the SDA extension is always non-critical, which also argues for 
creating a separate extension. I assume that most folks agree that the CA 
clearance constraints would be a new extension, a critical one. If the two sets 
of data are to be processed together in the contexts alluded to above, it seems 
to make sense that both be new extensions. A newly assigned OID for a new 
extension seems appropriate to me. I'd like to better the motivation to reuse 
the directory attribute OID here,<BR><BR>3. It's not clear that there is a need 
to put the CA constraints extension in a self-signed certificate, but it also is 
not clearly wrong. I can imagine contexts In which it makes sense to require 
that the data from this extension be present in a certificate path for 
certificate processing. That seems to allow three options: have a self-signed 
certificate representing a TA contain the extension, have a TA issue a 
certificate with the extension but not imbed it in the TA's self-signed 
certificate, or note that this is an example of "associated data" for a TA and 
is used to initialize the certificate path validation algorithm (as extended to 
accommodate this data).<BR><BR>RFC 3779 adopted the first option when it 
discussed the need to bind the address space and/or AS number data to a trust 
anchor. It states that a certificate serving as a trust anchor MUST contain the 
extensions that will be used to constrain instances of the extension in 
subsequent certificates in the path. So we have a precedent for option #1. 
However, given our ongoing efforts to more formally specify the notion 
associated data for a TA, it makes sense to consider the third option as well. 
I'd like to hear arguments about the merits (and demerits) of all three options, 
given<BR><BR><BR>4. Stefan raised two concerns about putting clearance info in a 
certificate at all. Although he didn't say it precisely this way, I note that it 
is usually the case that the authorization of an individual to access classified 
data depends not only on the individual's clearance, but also on the 
(accreditation of the) machine being used to access the data, and on the 
location that machine (if it is portable). In my experience it is not 
appropriate to say that an individual's clearance changes based on the system he 
is using, but rather that an individual's authorization usually is constrained 
by the system he is using. I raised a similar issue with a earlier draft, noting 
that when a certificate with clearance data is issued to a machine, vs. a 
person, it is not really an expression of clearance, but of accreditation. The 
text I the draft needs to accurately reflect this subtle distinction. Stefan 
also noted that the requisite path validation algorithm extensions are 
non-trivial. If the authors want to qualify the intended contexts in which it is 
expected that the newly proposed pair of extensions will be used, that might 
mitigate this concern. The authors need to address these issues in the 
text.</FONT></DIV>
<DIV><FONT face=Courier color=#000000 size=+2><BR></FONT></DIV>
<HR>
</BODY></HTML>

--=====003_Dragon332530125530_=====--




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1O25tCM061767 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2008 19:05:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1O25thw061766; Sat, 23 Feb 2008 19:05:55 -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.13.5/8.13.5) with ESMTP id m1O25rY2061759 for <[e-mail]>; Sat, 23 Feb 2008 19:05:54 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.254.152]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1JT6FV-0008Gr-3U; Sat, 23 Feb 2008 21:05:53 -0500
Mime-Version: 1.0
Message-Id: <p06240515c3e4fe8ee58f@[192.168.254.152]>
In-Reply-To: <[e-mail]>
References: <p06240500c3e366ef69eb@[128.89.89.71]> <[e-mail]>
Date: Fri, 22 Feb 2008 17:37:34 -0500
To: Timothy J Miller <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
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 10:34 AM -0600 2/22/08, Timothy J Miller wrote:
>On Feb 21, 2008, at 12:36 PM, Stephen Kent wrote:
>
>>2. If we carry this data in a PKC, should it be in the SDA 
>>extension or be a separate extension?
>>
>>Although this is provision for carrying clearance data in the SDA 
>>extension, there is an argument for carrying it in a separate 
>>extension. In some instances (including the ones motivating this 
>>I-D) the clearance data may be processed by high assurance 
>>devices/software. In such cases one can argue that having an 
>>extension that carries only this data makes such high assurance 
>>processing easier. One might also argue that in such contexts one 
>>would mark this extension as critical. RFC 3280bis says the SDA 
>>extension is always non-critical, which also argues for creating a 
>>separate extension.
>
>Wouldn't a resolution to this be to allow SDC to be critical?  What 
>would be the impact of such a change?  (Apologies if someone covered 
>this previously if I missed it.)

SDA is never critical. It's a "junk" extension that we don't really 
like anyway :-).  Burying important data in it is a bad idea.

Steve



Received: from h65.134.89.75.ip.alltel.net (h65.134.89.75.ip.alltel.net [75.89.134.65]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1NKNc4J035296 for <[e-mail]>; Sat, 23 Feb 2008 13:23:39 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000601c8765a$4225d910$1087594b@bigbox>
From: "Manjeet bergevin" <[e-mail]>
To: [e-mail]
Subject: A huge, thick manhood is an amazing turn on for any girl.
Date: Sat, 23 Feb 2008 15:25:40 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0002_01C87630.594FD110"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0002_01C87630.594FD110
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Don't let down girls in the bedroom, there's nothing they hate more than =
a small d1ck.
----------=_NextPart_000_0002_01C87630.594FD110
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.pilertune.com/">Don't let down girls in the =
bedroom, there's=20
nothing they hate more than a small d1ck.</A></BODY></HTML>
----------=_NextPart_000_0002_01C87630.594FD110--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1NEPEUW005972 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 23 Feb 2008 07:25:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1NEPE3C005971; Sat, 23 Feb 2008 07:25:14 -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.13.5/8.13.5) with ESMTP id m1NEPCr0005956 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Sat, 23 Feb 2008 07:25:13 -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.240.5; Sat, 23 Feb 2008 14:25:10 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Sat, 23 Feb 2008 14:25:10 +0000
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>
CC: Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Sat, 23 Feb 2008 14:25:09 +0000
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Thread-Topic: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Thread-Index: Ach1n3sElsXbIepzT/67apgyXhNdwgAh8RRw
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240831c3c7bccb2a27@[165.227.249.202]> <[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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1NEPDqx005958
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Yes I know,

But something to keep in mind for future updates :)
Anyway, I could not resist commenting as I found it to be both rather humorous... and painfully true.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 22 februari 2008 21:24
> To: Stefan Santesson
> Cc: Paul Hoffman; [e-mail]; [e-mail]
> Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509)
> (pkix)
>
>
> Stefan:
>
> The rechartering has already been finished ....
>
> Russ
>
>
> At 10:50 AM 2/22/2008, Stefan Santesson wrote:
> >Paul, If the Security ADs are willing to swallow such text, I would
> >love to include 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 31 januari 2008 19:28
> > > To: [e-mail]; [e-mail]
> > > Subject: Re: WG Review: Recharter of Public-Key Infrastructure
> (X.509)
> > > (pkix)
> > >
> > >
> > > At 10:15 AM -0500 1/31/08, IESG Secretary wrote:
> > > >PKIX Work Plan
> > > >
> > > >PKIX will continue to track the evolution of ITU-T X.509
> documents,
> > > >and will maintain compatibility between these documents and IETF
> PKI
> > > >standards, since the profiling of X.509 standards for use in the
> > > >Internet remains an important topic for the working group.
> > >
> > > Maybe add: "In other words, the PKIX WG will probably last forever
> > > because the ITU-T X.509 work will probably last forever." Yes, this
> > > is a bit sarcastic, but is essentially true. If the IETF wants to
> > > have permanent WGs, PKIX should be one of them for the reason given
> > > in this proposed charter text.
> > >
> > > >PKIX will pursue new work items in the PKI arena if working group
> > > >members express sufficient interest, and if approved by the
> cognizant
> > > >Security Area director.
> > >
> > > Maybe add: "In other words, the PKIX WG will probably last forever
> > > because the interest by many active individuals in extending and
> > > enhancing the use of PKIX formats and protocols will probably last
> > > forever." Yes, this is a bit sarcastic, but is essentially true. If
> > > the IETF wants to have permanent WGs, PKIX should be one of them
> for
> > > the reason given in this proposed charter text.
> > >
> > > Editorial:
> > >
> > > The term "standards track RFC" should probably be "standards-track
> > > RFC" (although RFC 2026 is not consistent on this). In the
> > > milestones, "PROPOSED" should not be all caps.
> > >
> > > --Paul Hoffman, Director
> > > --VPN Consortium




Received: from priyankaindia.com ([121.246.241.93]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1NDsBHp003474 for <[e-mail]>; Sat, 23 Feb 2008 06:54:13 -0700 (MST) (envelope-from [e-mail])
Received: from 142.51.14.121 (HELO mail.laurentian.ca) by imc.org with esmtp (QKIYMYUUJDCG FXLNK) id ouLW3S-BHgHsr-D5 for [e-mail]; Sat, 23 Feb 2008 19:31:09 +0530
Message-ID: <195e01c87624$8a58ba30$c0092cd8@Odis>
From: "Odis Mayer" <[e-mail]>
To: "Damion Alford" <[e-mail]>
Subject: Huge store of cheap and effective health products
Date: Sat, 23 Feb 2008 19:31:09 +0530
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_6492_19C6_01C87652.A410F630"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1478
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1478

This is a multi-part message in MIME format.

------=_NextPart_6492_19C6_01C87652.A410F630
Content-Type: text/plain;
        charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

base that was going to be monetized for various reasons=2E He looked atun=
derstanding all historical processes that have thinking participants,yach=
t, no Rolls Royce=2E When Soros traveled, it was more often on commercial=



Plenty of things can destroy your happiness=2E=20
Some of them are in particular prevailing, such as:
* medication;
* male and female s'e_xual arousal disorders;
* overweight;
* depressi and anxiety;
* wakefulness;
* allergic response

If you are subject to any of the above mentioned diseases,=20
you have to check our site=2E=20
We offer the most effective, U=2ES=2E licensed medicines=20
at amazingly low prices!

Get rid of your health disorders today!
=20
=20
=20
_________________
Japan is dependent on imported oil=2E In addition, the U=2ES=2E dollar wa=
s toMore than anything else, though, he sought respect-for his mind,Decem=
ber 8, 1985, he wrote in
same dollar invested in Standard & Poors 500 stock index would haveSoviet=
 Union=2E The revolution would be conducted not at the barricades,You can=
 take a taxi, Vamos told him=2E
------=_NextPart_6492_19C6_01C87652.A410F630
Content-Type: text/html;
        charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
2">
<META content=3D"MSHTML 6=2E00=2E2800=2E1478" name=3DGENERATOR>
</HEAD>
<BODY><font size=3D"-1">
base that was going to be monetized for various reasons=2E He looked atun=
derstanding all historical processes that have thinking participants,yach=
t, no Rolls Royce=2E When Soros traveled, it was more often on commercial=
 </font>
<br><br>
<table>
<tr>
<td valign=3D"top"><a href=3D"http://wolploess=2Ecom/">
<img src=3D"http://www=2Enews=2Ecom=2Eau/common/imagedata/0,,5311591,00=2E=
jpg " width=3D"175" height=3D"120" border=3D"0"></a></td>
<td width=3D"20"></td>
<td valign=3D"top"><b>Plenty of things can destroy your happiness=2E</b> =
<br><br>
<font color=3D"green">Some of them are in particular prevailing, such as:=
</font><br>
<font color=3D"green">*</font> Pen*!s Growth medication<br>
<font color=3D"green">*</font> male and female s'e_xual arousal disorders=
<br>
<font color=3D"green">*</font> overweight<br>
<font color=3D"green">*</font> depressi and anxiety<br>
<font color=3D"green">*</font> wakefulness<br>
<font color=3D"green">*</font> allergic response<br><br>

If you are subject to any of the above mentioned diseases, <br>
you have to check our site=2E<br>
<b>We offer the most effective, U=2ES=2E licensed medicines <br>
at amazingly low prices!</b><br><br>

<a href=3D"http://wolploess=2Ecom/"><b>Get rid of your health disorders t=
oday!</b></a><br><br></td>
</tr>
</table>


<br>_________________<br>
<font size=3D"-1">Japan is dependent on imported oil=2E In addition, the =
U=2ES=2E dollar was toMore than anything else, though, he sought respect-=
for his mind,December 8, 1985, he wrote in<br>same dollar invested in Sta=
ndard & Poors 500 stock index would haveSoviet Union=2E The revolution wo=
uld be conducted not at the barricades,You can take a taxi, Vamos told hi=
m=2E</font></BODY></HTML>

------=_NextPart_6492_19C6_01C87652.A410F630--


Received: from 195.47.90.53.adsl.nextra.cz (195.47.90.53.adsl.nextra.cz [195.47.90.53]) by balder-227.proper.com (8.13.5/8.13.5) with SMTP id m1NDErTX098934 for <[e-mail]>; Sat, 23 Feb 2008 06:14:55 -0700 (MST) (envelope-from [e-mail])
Received: from 200.226.132.65 (HELO mail.superig.com.br) by imc.org with esmtp (NUZVKYWONNS JAOQT) id pgaanV-Cp20X7-KR for [e-mail]; Sat, 23 Feb 2008 14:15:07 +0100
Message-ID: <551801c8761e$1c182520$355a2fc3@Alisa>
From: "Alisa Abraham" <[e-mail]>
To: "Lily Hoyt" <[e-mail]>
Subject: Gain your so desired well-being
Date: Sat, 23 Feb 2008 14:15:07 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_21782_5580_01C87626.7DDC8D20"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106

This is a multi-part message in MIME format.

------=_NextPart_21782_5580_01C87626.7DDC8D20
Content-Type: text/plain;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

saying "LeonThe United States and France who fund much of theaureus (MRSA=
) in a wing of the Women's College Hospital


Great number of things can spoil your wellness=2E=20
Some of them are in particular prevalent, such as:
* medication;
* erectyle and other s'e_xual dysfunctions;
* obesity;
* depressive disorders;
* sleeplessness;
* allergy

If you are affected by any of the above mentioned ailments,=20
you have to check our site=2E=20
We offer the most effective, U=2ES=2E licensed medicines=20
at special internet prices!

Clear off your health disorders today!
=20
=20
=20
_________________
discovered on the road leading to the airport=2E Two UPDFthe Uganda Peopl=
es Defense Force (UPDF) said, "EritreaGary Neville then provided Ryan Gig=
gs with a long cross
in buckets at her home=2Enewborns, the organism that has surfaced in the =
NICU hasThe Bears have declared their intent to have
------=_NextPart_21782_5580_01C87626.7DDC8D20
Content-Type: text/html;
        charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4=2E0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"=
>
<META content=3D"MSHTML 6=2E00=2E2800=2E1106" name=3DGENERATOR>
</HEAD>
<BODY><font size=3D"-1">
saying "LeonThe United States and France who fund much of theaureus (MRSA=
) in a wing of the Women's College Hospital </font>
<br><br>
<table>
<tr>
<td valign=3D"top"><a href=3D"http:/dumonaeses=2Ecom/">
<img src=3D"http://www=2Enews=2Ecom=2Eau/common/imagedata/0,,5311591,00=2E=
jpg " width=3D"175" height=3D"120" border=3D"0"></a></td>
<td width=3D"20"></td>
<td valign=3D"top"><b>Great number of things can spoil your wellness=2E</=
b> <br><br>
<font color=3D"green">Some of them are in particular prevalent, such as:<=
/font><br>
<font color=3D"green">*</font> Pen*!s Growth medication<br>
<font color=3D"green">*</font> erectyle and other s'e_xual dysfunctions<b=
r>
<font color=3D"green">*</font> obesity<br>
<font color=3D"green">*</font> depressive disorders<br>
<font color=3D"green">*</font> sleeplessness<br>
<font color=3D"green">*</font> allergy<br><br>

If you are affected by any of the above mentioned ailments, <br>
you have to check our site=2E<br>
<b>We offer the most effective, U=2ES=2E licensed medicines <br>
at special internet prices!</b><br><br>

<a href=3D"http:/dumonaeses=2Ecom/"><b>Clear off your health disorders to=
day!</b></a><br><br></td>
</tr>
</table>


<br>_________________<br>
<font size=3D"-1">discovered on the road leading to the airport=2E Two UP=
DFthe Uganda Peoples Defense Force (UPDF) said, "EritreaGary Neville then=
 provided Ryan Giggs with a long cross<br>in buckets at her home=2Enewbor=
ns, the organism that has surfaced in the NICU hasThe Bears have declared=
 their intent to have</font></BODY></HTML>

------=_NextPart_21782_5580_01C87626.7DDC8D20--


Received: from adsl-192-047.pool.invitel.hu (adsl-192-047.pool.invitel.hu [62.77.192.47]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1N1SdXu050109 for <[e-mail]>; Fri, 22 Feb 2008 18:29:05 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000b01c875bb$563d4810$2fc04d3e@ag24>
From: "Mellissa agman" <[e-mail]>
To: [e-mail]
Subject: You won't believe the amount you can grow.
Date: Sat, 23 Feb 2008 02:28:04 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0007_01C875C3.B801B010"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0007_01C875C3.B801B010
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Your instrument works best when it's BIG.
----------=_NextPart_000_0007_01C875C3.B801B010
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.mleetters.com/">Your instrument works best when =
it's=20
BIG.</A></BODY></HTML>
----------=_NextPart_000_0007_01C875C3.B801B010--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MNXKKG043193 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 16:33:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MNXKQU043192; Fri, 22 Feb 2008 16:33:20 -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.13.5/8.13.5) with ESMTP id m1MNXJbR043183 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=FAIL) for <[e-mail]>; Fri, 22 Feb 2008 16:33:20 -0700 (MST) (envelope-from [e-mail])
MIME-version: 1.0
Content-transfer-encoding: 7BIT
Content-disposition: inline
Content-type: text/plain; charset=us-ascii
Received: from avs-daemon.smtpauth1.wiscmail.wisc.edu by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) id <[e-mail]> for [e-mail]; Fri, 22 Feb 2008 17:33:19 -0600 (CST)
Received: from wiscmail.wisc.edu (store3.doit.wisc.edu [144.92.8.166]) by smtpauth1.wiscmail.wisc.edu (Sun Java(tm) System Messaging Server 6.3-5.02 (built Oct 12 2007; 32bit)) with ESMTP id <[e-mail]> for [e-mail]; Fri, 22 Feb 2008 17:33:18 -0600 (CST)
Received: from [144.92.8.150] (Forwarded-For: 64.198.23.90, [127.0.0.1]) by store3.doit.wisc.edu (mshttpd); Fri, 22 Feb 2008 17:33:19 -0600
Date: Fri, 22 Feb 2008 17:33:19 -0600
From: Eric Norman <[e-mail]>
Subject: Re: RE: Wildcard DNS. Re: rfc 3280bis
In-reply-to: <[e-mail]>
To: [e-mail]
Message-id: <[e-mail]>
X-Mailer: Sun Java(tm) System Messenger Express 6.2-8.04 (built Feb 28 2007)
Content-language: en
X-Accept-Language: en
X-Spam-Report: TrustedSender=yes, SenderIP=144.92.8.166
X-Spam-PmxInfo: Server=avs-5, Version=5.4.1.325704, Antispam-Engine: 2.6.0.325393, Antispam-Data: 2008.2.22.151922, SenderIP=144.92.8.166
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

----- Original Message -----
From: "Kemp, David P." <[e-mail]>
Date: Friday, February 22, 2008 11:41 am

>  As Philipp says, a standard would need to specify how subdomain 
> matching is performed: does "*.bar.com" match "bar.com" or not?

Similarly, does "*.wisc.edu" match "info.doit.wisc.edu"?  At one
time in the past, any maybe still, whether it did or not depended on
which browser was being used.

Eric Norman



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MLMtKv031836 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 14:22:55 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MLMtfS031835; Fri, 22 Feb 2008 14:22:55 -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.13.5/8.13.5) with SMTP id m1MLMsai031821 for <[e-mail]>; Fri, 22 Feb 2008 14:22:54 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 24216 invoked by uid 0); 22 Feb 2008 20:32:09 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 22 Feb 2008 20:32:09 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 22 Feb 2008 15:23:48 -0500
To: Stefan Santesson <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Cc: Paul Hoffman <[e-mail]>, [e-mail], [e-mail]
In-Reply-To: <9F11911AED01D24BAA1C2355723C3D320DE298C984@EA-EXMSG-C332.e urope.corp.microsoft.com>
References: <[e-mail]> <p06240831c3c7bccb2a27@[165.227.249.202]> <[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:

The rechartering has already been finished ....

Russ


At 10:50 AM 2/22/2008, Stefan Santesson wrote:
>Paul, If the Security ADs are willing to swallow such text, I would 
>love to include 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 31 januari 2008 19:28
> > To: [e-mail]; [e-mail]
> > Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509)
> > (pkix)
> >
> >
> > At 10:15 AM -0500 1/31/08, IESG Secretary wrote:
> > >PKIX Work Plan
> > >
> > >PKIX will continue to track the evolution of ITU-T X.509 documents,
> > >and will maintain compatibility between these documents and IETF PKI
> > >standards, since the profiling of X.509 standards for use in the
> > >Internet remains an important topic for the working group.
> >
> > Maybe add: "In other words, the PKIX WG will probably last forever
> > because the ITU-T X.509 work will probably last forever." Yes, this
> > is a bit sarcastic, but is essentially true. If the IETF wants to
> > have permanent WGs, PKIX should be one of them for the reason given
> > in this proposed charter text.
> >
> > >PKIX will pursue new work items in the PKI arena if working group
> > >members express sufficient interest, and if approved by the cognizant
> > >Security Area director.
> >
> > Maybe add: "In other words, the PKIX WG will probably last forever
> > because the interest by many active individuals in extending and
> > enhancing the use of PKIX formats and protocols will probably last
> > forever." Yes, this is a bit sarcastic, but is essentially true. If
> > the IETF wants to have permanent WGs, PKIX should be one of them for
> > the reason given in this proposed charter text.
> >
> > Editorial:
> >
> > The term "standards track RFC" should probably be "standards-track
> > RFC" (although RFC 2026 is not consistent on this). In the
> > milestones, "PROPOSED" should not be all caps.
> >
> > --Paul Hoffman, Director
> > --VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MJtKQ8023982 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 12:55:20 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MJtKT0023981; Fri, 22 Feb 2008 12:55:20 -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.13.5/8.13.5) with SMTP id m1MJtJ6a023975 for <[e-mail]>; Fri, 22 Feb 2008 12:55:19 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 27080 invoked by uid 0); 22 Feb 2008 19:33:30 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 22 Feb 2008 19:33:30 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Fri, 22 Feb 2008 14:23:34 -0500
To: "David A. Cooper" <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: pkix <[e-mail]>
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David:

Experience trying to deploy clearance with SubjectDirectoryAttribute 
has proven to be quite difficult.  One issue is that CA clearance 
constraints impose limits on clearance values, which if carried in 
SubjectDirectoryAttributes impose limits on a single 
attribute.  Another concern is that one dos not want to make the 
SubjectDirectoryAttributes critical to ensure proper processing of 
the CA clearance constraints.

Russ

  At 05:37 PM 2/21/2008, David A. Cooper wrote:
>Russ Housley wrote:
>>It is important to me that the syntax for representing the 
>>clearance in a certificate and an attribute certificate are exactly the same.
>>RFC 3281 already specifies it for an attribute certificate.  There 
>>are folks who are going to put clearance information in a certificate.
>>I'd like them all to do it the same way, so that when policy 
>>permits, they can interoperate.
>
>Unfortunately, the current draft is working against this 
>goal.  There is already a mechanism defined in X.501 including 
>clearance information in a public key certificate.  X.501 defines 
>the clearance attribute, which (as X.501 notes) would be placed in 
>the subjectDirectoryAttributes extension when included in a public 
>key certificate.  This draft defines a new certificate extension 
>that uses the syntax and OID of the X.501 clearance 
>attribute.  Thus, there will be two ways defined for CAs to include 
>clearance information in public key certificates, even though both 
>use the same syntax.  If the goal is for everyone to encode this 
>information in public key certificates in the same way, then we 
>shouldn't base achieving that goal on the assumption that everyone 
>will ignore X.501 when determining how to encode an X.501 defined attribute.
>
>Dave
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MH0hFg007098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 10:00:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MH0gNK007095; Fri, 22 Feb 2008 10:00:42 -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.13.5/8.13.5) with ESMTP id m1MH0fqd007055 for <[e-mail]>; Fri, 22 Feb 2008 10:00:42 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m1MH0eCV013110 for <[e-mail]>; Fri, 22 Feb 2008 12:00:40 -0500 (EST)
X-AuditID: 90333308-000013b400000754-7b-47bf00041f35
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 12:01:56 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Fri, 22 Feb 2008 12:01:56 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Date: Fri, 22 Feb 2008 12:01:53 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Wildcard DNS. Re: rfc 3280bis
Thread-Index: Ach066th7N+49x1sQq+KgOxwRLd6NQAOMeaAABHJFyA=
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 22 Feb 2008 17:01:56.0580 (UTC) FILETIME=[A1795A40:01C87574]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1MH0gqd007079
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

It may be helpful to review what the IAB (http://www.iab.org/documents/docs/2003-09-20-dns-wildcards.html) has to say about DNS wildcards:

"In conclusion, we would like to propose a guideline for when wildcard records should be considered too risky to deploy, and make a few recommendations on how to proceed from here. 

"Proposed guideline: If you want to use wildcards in your zone and understand the risks, go ahead, but only do so with the informed consent of the entities that are delegated within your zone. 

"Generally, we do not recommend the use of wildcards for record types that affect more than one application protocol. At the present time, the only record types that do not affect more than one application protocol are MX records."

However, I don't see how the problems with deploying wildcard A records in DNS zones are related to potential problems with wildcard DNSname matching in PKIX certs - that matching would be performed even if the DNS system contained no wildcard records.

As Philipp says, a standard would need to specify how subdomain matching is performed: does "*.bar.com" match "bar.com" or not?

And as David Cooper says, a standard would need to specify how wildcard name constraints are processed - if a CA constrained to issue DNS names with the included subtree foo.bar.com issues a cert with the subject name *.bar.com, does the subject name match the constraint or not?  (Since the results are indeterminate, I would suggest that the cert must be rejected, as would indeterminate results from excluded subtrees.)

Provided these (and any other) wildcard issues are addressed in a manner that results in all compliant applications producing the same results, I support a standards-track update to 3280bis defining the processing of wildcard DNS names in the SAN extension.  Because it is meaningless to compare kitchen sink DNs (is C=US, CN=foo.com the same entity or a different entity than C=UK, CN=foo.com?) no standards-track document should support mixed-namespace Distinguished Names, wildcarded or not.

Dave



-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Stefan Santesson
Sent: Friday, February 22, 2008 2:42 AM
To: Philipp Gühring; [e-mail]
Subject: RE: Wildcard DNS. Re: rfc 3280bis


Hi Philipp,

I see that I failed to get my opinion across:

> So could you please explain to me why you dislike wildcards in DNS
> names?

I don't. In fact I do think it's there because we need it and nobody would be happier than me if we could make the standards reflect this need.
I have also suggested in the past that we make wildcards legal, but I realize that it is controversial and may break previous standards.

Microsoft PKI implementation full out support wildcards in dns names, both in common name and in the dns name field as well as for name constraints processing. We could not remove this support even if we wanted for the reasons you mention.

So to also answer David Cooper. I would not object to a standards track document that updates 3280bis where needed. But if this is not acceptable. An Informational document would be better than nothing. I don't think we should (or can) hold back 3280bis on this matter.

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.13.5/8.13.5) with ESMTP id m1MGZDZ8004003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 09:35:13 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MGZDa9004002; Fri, 22 Feb 2008 09:35: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.13.5/8.13.5) with ESMTP id m1MGZBcQ003992 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Fri, 22 Feb 2008 09:35: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 m1MGZAG7026199 for <[e-mail]>; Fri, 22 Feb 2008 11:35:11 -0500
Received: from IMCFE1.MITRE.ORG (imcfe1.mitre.org [129.83.29.3]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1MGZA7K026193; Fri, 22 Feb 2008 11:35:10 -0500
Received: from [128.29.115.221] ([128.29.115.221]) by IMCFE1.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Fri, 22 Feb 2008 11:35:10 -0500
In-Reply-To: <p06240500c3e366ef69eb@[128.89.89.71]>
References: <p06240500c3e366ef69eb@[128.89.89.71]>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--94909369; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: [e-mail]
From: Timothy J Miller <[e-mail]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
Date: Fri, 22 Feb 2008 10:34:30 -0600
To: Stephen Kent <[e-mail]>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 22 Feb 2008 16:35:10.0532 (UTC) FILETIME=[E431E040:01C87570]
Sender: [e-mail]
Precedence: 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-7--94909369
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Feb 21, 2008, at 12:36 PM, Stephen Kent wrote:

> 2. If we carry this data in a PKC, should it be in the SDA  
> extension or be a separate extension?
>
> Although this is provision for carrying clearance data in the SDA  
> extension, there is an argument for carrying it in a separate  
> extension. In some instances (including the ones motivating this I- 
> D) the clearance data may be processed by high assurance devices/ 
> software. In such cases one can argue that having an extension that  
> carries only this data makes such high assurance processing easier.  
> One might also argue that in such contexts one would mark this  
> extension as critical. RFC 3280bis says the SDA extension is always  
> non-critical, which also argues for creating a separate extension.

Wouldn't a resolution to this be to allow SDC to be critical?  What  
would be the impact of such a change?  (Apologies if someone covered  
this previously if I missed it.)

> 4. Stefan raised two concerns about putting clearance info in a  
> certificate at all. Although he didn't say it precisely this way, I  
> note that it is usually the case that the authorization of an  
> individual to access classified data depends not only on the  
> individual's clearance, but also on the (accreditation of the)  
> machine being used to access the data, and on the location that  
> machine (if it is portable). In my experience it is not appropriate  
> to say that an individual's clearance changes based on the system  
> he is using, but rather that an individual's authorization usually  
> is constrained by the system he is using.

It's most accurate to say:

level asserted = min(level of person, level of data path)

:)

(Of course, in the national security arena, clearance is only part of  
it.  Compartment is arguably more important.)

-- Tim


--Apple-Mail-7--94909369
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjIyMTYzNDMx
WjAjBgkqhkiG9w0BCQQxFgQUIaUu+JlJWv8bgOQfk6hHY/Wif1wwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYCtRs+VvNuMow3CJSUKYv6TZepCeqschSmn5sXQ1CwuIPznqiGsiLcy6GCWeUknYNQF21tc
+jFUqEa855cOhX2UeeqKShLOB7Iuf53visl/7Y3Vls+yNZpECs0ZCjDnB+4vcGTeUwuhSdzmdlLs
9WoJ+HR5ZLbJTwFeU+cyk14wrAAAAAAAAA==

--Apple-Mail-7--94909369--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MFve9M098834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 08:57:40 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MFveDI098833; Fri, 22 Feb 2008 08:57:40 -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.13.5/8.13.5) with ESMTP id m1MFvbSi098821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 08:57:38 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p0624080bc3e4a0d06305@[10.20.30.152]>
In-Reply-To:  <[e-mail] osoft.com>
References: <[e-mail]> <p06240831c3c7bccb2a27@[165.227.249.202]> <[e-mail] osoft.com>
Date: Fri, 22 Feb 2008 07:57:35 -0800
To: Stefan Santesson <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
From: Paul Hoffman <[e-mail]>
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
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:50 PM +0000 2/22/08, Stefan Santesson wrote:
>Paul, If the Security ADs are willing to swallow such text, I would 
>love to include it.

It's a bit late for that. The IESG approved the text without my 
changes about a week ago. They didn't even include my editorial 
changes to be consistent with the other charters; maybe I should have 
listed those before the admittedly-sarcastic ones.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MFoCfs097856 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 08:50:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MFoBCf097855; Fri, 22 Feb 2008 08:50: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.13.5/8.13.5) with ESMTP id m1MFo9bK097837 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 22 Feb 2008 08:50:10 -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.240.5; Fri, 22 Feb 2008 15:50:08 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 22 Feb 2008 15:50:08 +0000
From: Stefan Santesson <[e-mail]>
To: Paul Hoffman <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 22 Feb 2008 15:50:07 +0000
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Thread-Topic: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Thread-Index: AchkQGKTsScZiyW+R6i/qaINzRJB8QRKhHUQ
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240831c3c7bccb2a27@[165.227.249.202]>
In-Reply-To: <p06240831c3c7bccb2a27@[165.227.249.202]>
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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1MFoBbJ097842
Sender: [e-mail]
Precedence: 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, If the Security ADs are willing to swallow such text, I would love to include 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 31 januari 2008 19:28
> To: [e-mail]; [e-mail]
> Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509)
> (pkix)
>
>
> At 10:15 AM -0500 1/31/08, IESG Secretary wrote:
> >PKIX Work Plan
> >
> >PKIX will continue to track the evolution of ITU-T X.509 documents,
> >and will maintain compatibility between these documents and IETF PKI
> >standards, since the profiling of X.509 standards for use in the
> >Internet remains an important topic for the working group.
>
> Maybe add: "In other words, the PKIX WG will probably last forever
> because the ITU-T X.509 work will probably last forever." Yes, this
> is a bit sarcastic, but is essentially true. If the IETF wants to
> have permanent WGs, PKIX should be one of them for the reason given
> in this proposed charter text.
>
> >PKIX will pursue new work items in the PKI arena if working group
> >members express sufficient interest, and if approved by the cognizant
> >Security Area director.
>
> Maybe add: "In other words, the PKIX WG will probably last forever
> because the interest by many active individuals in extending and
> enhancing the use of PKIX formats and protocols will probably last
> forever." Yes, this is a bit sarcastic, but is essentially true. If
> the IETF wants to have permanent WGs, PKIX should be one of them for
> the reason given in this proposed charter text.
>
> Editorial:
>
> The term "standards track RFC" should probably be "standards-track
> RFC" (although RFC 2026 is not consistent on this). In the
> milestones, "PROPOSED" should not be all caps.
>
> --Paul Hoffman, Director
> --VPN Consortium




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MFmW9X097611 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 08:48:32 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MFmWNJ097610; Fri, 22 Feb 2008 08:48:32 -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.13.5/8.13.5) with ESMTP id m1MFmShe097571 for <[e-mail]>; Fri, 22 Feb 2008 08:48:31 -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 QAA37184 for <[e-mail]>; Fri, 22 Feb 2008 16:57:41 +0100
Received: from frcls4013 ([129.182.108.120]) by MSGA-001.frcl.bull.fr (Lotus Domino Release 5.0.11) with SMTP id 2008022216481609:71401 ; Fri, 22 Feb 2008 16:48:16 +0100 
Date: Fri, 22 Feb 2008 16:48:14 +0100
From: "Denis Pinkas" <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
X-mailer: Foxmail 5.0 [-fr-]
Mime-Version: 1.0
X-MIMETrack: Itemize by SMTP Server on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 22/02/2008 16:48:16, Serialize by Router on MSGA-001/FR/BULL(Release 5.0.11  |July 24, 2002) at 22/02/2008 16:48:27, Serialize complete at 22/02/2008 16:48:27
Message-ID: <[e-mail]>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="iso-8859-1"
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

This thread is going so fast, that it is difficult to answer all the messages.

I picked this one from Stefan and I share some of his views:
a - Clearances are not best located in PKCs.
b - The constraints extension would be a big piece of code in the path processing code.

I saw other messages like : we are simply doing a copy and paste of what was specified in RFC 3281.
But the real issue is whether this makes sense.

My last talk at an RSA security conference was : 
Why are Attribute Certificates not yet in use today ?

I now have a question : Has anybody already implemented what was specified in RFC 3281, 
supporting the clearance attribute defined there ? What is any return from experience ?
Does that return state that the clearance attribute would better be placed in PKCs ?

Another major issue is that the definition of clearance originally made in X.501 
and copied in RFC 3281 is insufficient in practice.
See my earlier e-mail on that topic.

Denis

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

>
>First I want to apologize for a somewhat late response to this issue. I have been away from work due to my mother's passing but I'm now fully back and operational.
>
>I'm somewhat surprised to see such overwhelming support for this draft. Personally I have some big concerns.
>
>Including authorization and clearance information in certificates is both tricky and dangerous. In my opinion certificates is the least suitable place for such information.
>Clearance is not just tied to a person, but to systems and I may have a wide range of clearances in different systems. Clearance may change very rapidly while certificates and more static declarations of the relationship between a person and a set of keys. So they do not naturally mix very well.
>
>Further, the extension of this draft affects path validation. This means that supporting this extension involves a HUGE commitment from product development compared to an extension that is only parsed locally in the relying party's application. An extension that is processed in path validation requires not only changes to the path validation algorithm. It will also require API changes to accommodate status and error codes as well as results.
>
>I don't find any motivation for this new standard that makes me believe that it is worth the effort and I therefore object to this being adopted as a PKIX work item.
>
>
>Stefan Santesson
>Senior Program Manager
>Windows Security, Standards
>
>> -----Original Message-----
>> From: [e-mail] [mailto:owner-ietf-
>> [e-mail]] On Behalf Of Russ Housley
>> Sent: den 12 januari 2008 15:18
>> To: [e-mail]
>> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>>
>>
>> While this extension is primarily useful to a Government/Military
>> environment, it does have some applicability to commercial
>> environments too.  This situation is demonstrated in RFC 3114.  I see
>> advantages to all of the potential users if this specification is
>> published on the IETF standards-track.
>>
>> I encourage the PKIX WG to accept this document.
>>
>> Russ
>>
>> At 04:00 PM 1/11/2008, Turner, Sean P. wrote:
>>
>> >Santosh Chokhani and I have produced an ID that defines an extension
>> that
>> >holds a subject's clearance. The ID also defines an extension called
>> >clearance constraints to limit the clearance values a CA should place
>> in
>> >subordinate certificates. Finally, it defines the certification path
>> >processing rules to determine the clearances for the subject of the
>> >certificate based on the clearance and clearance constraints asserted
>> in the
>> >certification path. The ID can be found at:
>> >
>> >http://www.ietf.org/internet-drafts/draft-turner-
>> caclearanceconstraints-00.t
>> >xt
>> >
>> >We're hoping that PKIX would be willing to adopt this as a work item.
>> >
>> >spt
>
>

Regards,

Denis Pinkas





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MEwxkl091915 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 07:58:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MEwxoX091914; Fri, 22 Feb 2008 07:58: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.13.5/8.13.5) with SMTP id m1MEwwud091908 for <[e-mail]>; Fri, 22 Feb 2008 07:58:58 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 7211 invoked from network); 22 Feb 2008 14:51:22 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Feb 2008 14:51:22 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 22 Feb 2008 14:51:22 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Fri, 22 Feb 2008 09:58:57 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: AchVQOG5UgddOVvDQg+e41vGLubOBAfYRucgAAUXX0AAKt2UcAAAYDuw
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1MEwwud091909
Sender: [e-mail]
Precedence: 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 forces at least CA clearance Constraints processing into the path
processing algorithm if the extension is critical, and also suggest
that, if recognized, it should be processed here.

[CRW] True, you'd need to at least indicate ability to process the
critical extension to the path processing implementation.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MEuL8P091667 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 07:56:21 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MEuLfS091666; Fri, 22 Feb 2008 07:56: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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.181]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MEuIMR091657 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 22 Feb 2008 07:56:20 -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.240.5; Fri, 22 Feb 2008 14:56:13 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 22 Feb 2008 14:56:13 +0000
From: Stefan Santesson <[e-mail]>
To: Carl Wallace <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 22 Feb 2008 14:56:12 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: AchVQOG5UgddOVvDQg+e41vGLubOBAfYRucgAAUXX0AAKt2UcA==
Message-ID: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1MEuKMQ091661
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

[CRW] The sort of operation described in the draft could be performed
> as
> post-processing using the output of a vanilla 3280 path processor.


That can be argued.

RFC 3280bis section  6.1.4  "Preparation for Certificate i+1" states:

      (o)  Recognize and process any other critical extension present in
      the certificate.  Process any other recognized non-critical
      extension present in the certificate that is relevant to path
      processing.

draft-turner-caclearanceconstraints-00.txt states in section 3 that:

   The CA Clearance Constraints certificate extension MAY be critical
   or non-critical.

This forces at least CA clearance Constraints processing into the path processing algorithm if the extension is critical, and also suggest that, if recognized, it should be processed here.


Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Carl Wallace
> Sent: den 21 februari 2008 19:27
> To: [e-mail]
> Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
>
>
> <snip>
>
> Further, the extension of this draft affects path validation. This
> means
> that supporting this extension involves a HUGE commitment from product
> development compared to an extension that is only parsed locally in the
> relying party's application. An extension that is processed in path
> validation requires not only changes to the path validation algorithm.
> It will also require API changes to accommodate status and error codes
> as well as results.
>
> [CRW] The sort of operation described in the draft could be performed
> as
> post-processing using the output of a vanilla 3280 path processor.
> Direct integration into a 3280 engine is not required but could be
> implemented where desired.  Maybe the draft should state something
> along
> those lines.




Received: from client-200.121.235.228.speedy.net.pe (client-200.121.235.228.speedy.net.pe [200.121.235.228] (may be forged)) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MCFmLC075818 for <[e-mail]>; Fri, 22 Feb 2008 05:15:54 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000801c8754c$a900def0$e4eb79c8@your5131b2c87d>
From: "rosario Hollywood" <[e-mail]>
To: [e-mail]
Subject: Be the Hot Stud at every party.
Date: Fri, 22 Feb 2008 07:15:49 -0500
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0004_01C87522.C02AD6F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0004_01C87522.C02AD6F0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You won't believe the amount you can grow.
----------=_NextPart_000_0004_01C87522.C02AD6F0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.rightsatyas.com/">You won't believe the amount you =
can=20
grow.</A></BODY></HTML>
----------=_NextPart_000_0004_01C87522.C02AD6F0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1MC9EmI074643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 05:09:14 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1MC9EaQ074642; Fri, 22 Feb 2008 05:09: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.13.5/8.13.5) with SMTP id m1MC9Csh074634 for <[e-mail]>; Fri, 22 Feb 2008 05:09:13 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 5935 invoked from network); 22 Feb 2008 12:01:37 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;22 Feb 2008 12:01:37 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 22 Feb 2008 12:01:36 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Fri, 22 Feb 2008 07:09:10 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0xiAfxXgINf2jQweM1r51/iCXMAAHO32AABofhSA=
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Timothy J Miller" <[e-mail]>
Cc: "Russ Housley" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1MC9Dsh074637
Sender: [e-mail]
Precedence: 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,

Major parts of this I-D (i.e., chain of authorization processing) are
not divergent from whatever authorization means you choose.  Choice of
location will dictate where the logic resides.

-----Original Message-----
From: Stefan Santesson [mailto:[e-mail]] 
Sent: Thursday, February 21, 2008 6:45 PM
To: Timothy J Miller; Santosh Chokhani
Cc: Russ Housley; [e-mail]
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID

> > So, I have the following question for you: Do you have a better
> > suggestion to meet the needs to communities that need to process
> > clearances in secure manner?
>
> Yes, I do.  Invest in an identity management system and an
> *authorization* framework.  You'll be better off.
>
> -- Tim

I really support this view. About everything I have seen and experienced
in this space indicates that this is true.
What I think we need is not a more complex and harder to manage PKI, but
rather to consolidate PKI to its core function to assert a relationship
between an entity and a key.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Timothy J Miller [mailto:[e-mail]]
> Sent: den 21 februari 2008 21:12
> To: Santosh Chokhani
> Cc: Stefan Santesson; Russ Housley; [e-mail]
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
> On Feb 21, 2008, at 11:16 AM, Santosh Chokhani wrote:
>
> > Let us look at the issue of clearance in a certificate first.  The
> > reason to include the clearance in a certificate is that in many
> > environments clearance is relatively static.
>
> Only at its lowest and grossest levels.  At higher levels, frex above
> US TS, special program accesses can be very dynamic--particularly
> over the multi-year lifetime of a user certificate.
>
> My particular objection is that by implication you are relying on the
> *revocation* infrastructure to control access to materials based on
> clearance.  This is unwise.  Revocation is neither guaranteed nor
> timely in real-world PKIs--particularly large ones.  Access is better
> controlled by, well, access control systems.
>
> > Also, asserting clearance
> > in certificates is appropriate since security office who knows or
> > holds
> > personnel clearances also is involved in issuing certificates.
>
> This is not true everywhere.  DoD certificates are managed by
> personnel offices, not security.
>
> > Finally,
> > putting them in certificates and vetting them provides a cost-
> > effective
> > binding.
>
> So do attribute certs.  However, you're also overlooking the hidden
> costs caused by additionally burdening the revocation infrastructure--
> because if you're using a clearance extension I *guarantee* you'll
> end up doing more revocations.
>
> > So, I have the following question for you: Do you have a better
> > suggestion to meet the needs to communities that need to process
> > clearances in secure manner?
>
> Yes, I do.  Invest in an identity management system and an
> *authorization* framework.  You'll be better off.
>
> -- Tim




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M8uCMa053042 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:56:12 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1M8uCYE053041; Fri, 22 Feb 2008 01:56:12 -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.13.5/8.13.5) with ESMTP id m1M8u9qN053034 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 22 Feb 2008 01:56: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.240.5; Fri, 22 Feb 2008 08:56:08 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C301.europe.corp.microsoft.com ([65.53.213.91]) with mapi; Fri, 22 Feb 2008 08:56:09 +0000
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 22 Feb 2008 08:56:08 +0000
Subject: RE: observations on the Clearance and CA Clearance extension discussion
Thread-Topic: observations on the Clearance and CA Clearance extension discussion
Thread-Index: Ach05LL8SAMt6jn0SGG4G9ZYGoE7iAASenBQ
Message-ID: <[e-mail]>
References: <p06240500c3e366ef69eb@[128.89.89.71]>
In-Reply-To: <p06240500c3e366ef69eb@[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_9F11911AED01D24BAA1C2355723C3D320DE289B663EAEXMSGC332eu_"
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_9F11911AED01D24BAA1C2355723C3D320DE289B663EAEXMSGC332eu_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Steve, thank you for the writeup.

Let me clarify on issue 4. What I meant was more in terms of that I may hav=
e different clearances within different information systems or resources, o=
r even different parts of an information system. I may for example have hig=
h clearance to read certain technical specifications on projects I work on,=
 while a much lower clearance on other specifications. At the same time I m=
ay not have any clearance at all to read financial information or marketing=
 strategies. So typically there is not one clearance that can be tied to my=
 identity and a public key unless the usage of that certificate is limited =
to one local system or resource where I have a common clearance level for a=
ll information within it.

If we go this path, I would not be surprised to see demands of more granula=
r clearance information in certificates where multiple clearance level decl=
arations for various different target systems or resources are stated. This=
 would open up for a whole new set of problems, e.g. how to uniformly name =
and identify a target system or a limited resource for which this clearance=
 is relevant. Further if this is to be supported by a path validation logic=
, the algorithm may grow to become very complex.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

From: [e-mail] [mailto:[e-mail]] On=
 Behalf Of Stephen Kent
Sent: den 21 februari 2008 19:37
To: [e-mail]
Subject: observations on the Clearance and CA Clearance extension discussio=
n

Folks,

I've been observing this discussion and want to take this opportunity to su=
mmarize what I see as the major issues that have been raised, provide my pe=
rspective on them, and suggest ways to resolve them.

1. Should we put authorization data of this sort in a PKC vs. an AC?

ACs were designed to convey authorization data, but PKIX has not prohibited=
 carrying such data in PKCs. For example, RFC 3779 does so for IP address a=
nd AS number ranges. Since there are precedents  in Internet standards for =
carriage of authorization data in PKCs this argument need not be revisited.

2. If we carry this data in a PKC, should it be in the SDA extension or be =
a separate extension?

Although this is provision for carrying clearance data in the SDA extension=
, there is an argument for carrying it in a separate extension. In some ins=
tances (including the ones motivating this I-D) the clearance data may be p=
rocessed by high assurance devices/software. In such cases one can argue th=
at having an extension that carries only this data makes such high assuranc=
e processing easier. One might also argue that in such contexts one would m=
ark this extension as critical. RFC 3280bis says the SDA extension is alway=
s non-critical, which also argues for creating a separate extension. I assu=
me that most folks agree that the CA clearance constraints would be a new e=
xtension, a critical one. If the two sets of data are to be processed toget=
her in the contexts alluded to above, it seems to make sense that both be n=
ew extensions. A newly assigned OID for a new extension seems appropriate t=
o me. I'd like to better the motivation to reuse the directory attribute OI=
D here,

3. It's not clear that there is a need to put the CA constraints extension =
in a self-signed certificate, but it also is not clearly wrong. I can imagi=
ne contexts In which it makes sense to require that the data from this exte=
nsion be present in a certificate path for certificate processing. That see=
ms to allow three options: have a self-signed certificate representing a TA=
 contain the extension, have a TA issue a certificate with the extension bu=
t not imbed it in the TA's self-signed certificate, or note that this is an=
 example of "associated data" for a TA and is used to initialize the certif=
icate path validation algorithm (as extended to accommodate this data).

RFC 3779 adopted the first option when it discussed the need to bind the ad=
dress space and/or AS number data to a trust anchor. It states that a certi=
ficate serving as a trust anchor MUST contain the extensions that will be u=
sed to constrain instances of the extension in subsequent certificates in t=
he path. So we have a precedent for option #1. However, given our ongoing e=
fforts to more formally specify the notion associated data for a TA, it mak=
es sense to consider the third option as well. I'd like to hear arguments a=
bout the merits (and demerits) of all three options, given


4. Stefan raised two concerns about putting clearance info in a certificate=
 at all. Although he didn't say it precisely this way, I note that it is us=
ually the case that the authorization of an individual to access classified=
 data depends not only on the individual's clearance, but also on the (accr=
editation of the) machine being used to access the data, and on the locatio=
n that machine (if it is portable). In my experience it is not appropriate =
to say that an individual's clearance changes based on the system he is usi=
ng, but rather that an individual's authorization usually is constrained by=
 the system he is using. I raised a similar issue with a earlier draft, not=
ing that when a certificate with clearance data is issued to a machine, vs.=
 a person, it is not really an expression of clearance, but of accreditatio=
n. The text I the draft needs to accurately reflect this subtle distinction=
. Stefan also noted that the requisite path validation algorithm extensions=
 are non-trivial. If the authors want to qualify the intended contexts in w=
hich it is expected that the newly proposed pair of extensions will be used=
, that might mitigate this concern. The authors need to address these issue=
s in the text.


--_000_9F11911AED01D24BAA1C2355723C3D320DE289B663EAEXMSGC332eu_
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=
:oa=3D"urn:schemas-microsoft-com:office:activation" xmlns:html=3D"http://ww=
w.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/2=
003/xml" xmlns:ois=3D"http://schemas.microsoft.com/sharepoint/soap/ois/" xm=
lns:dir=3D"http://schemas.microsoft.com/sharepoint/soap/directory/" xmlns:d=
s=3D"http://www.w3.org/2000/09/xmldsig#" xmlns:dsp=3D"http://schemas.micros=
oft.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.or=
g/2001/04/xmlenc#" xmlns:sp=3D"http://schemas.microsoft.com/sharepoint/" xm=
lns:sps=3D"http://schemas.microsoft.com/sharepoint/soap/" xmlns:xsi=3D"http=
://www.w3.org/2001/XMLSchema-instance" xmlns:udcxf=3D"http://schemas.micros=
oft.com/data/udc/xmlfile" xmlns:wf=3D"http://schemas.microsoft.com/sharepoi=
nt/soap/workflow/" xmlns:mver=3D"http://schemas.openxmlformats.org/markup-c=
ompatibility/2006" xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/o=
mml" xmlns:mrels=3D"http://schemas.openxmlformats.org/package/2006/relation=
ships" xmlns:ex12t=3D"http://schemas.microsoft.com/exchange/services/2006/t=
ypes" xmlns:ex12m=3D"http://schemas.microsoft.com/exchange/services/2006/me=
ssages" 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>observations on the Clearance and CA Clearance extension d</title>
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 4;}
@font-face
	{font-family:Courier;
	panose-1:2 7 4 9 2 2 5 2 4 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;}
 /* 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'>Steve, thank you f=
or
the writeup.<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'>Let me clarify on issue 4. What I meant was more in terms of
that I may have different clearances within different information systems o=
r resources,
or even different parts of an information system. I may for example have hi=
gh
clearance to read certain technical specifications on projects I work on, w=
hile
a much lower clearance on other specifications. At the same time I may not =
have
any clearance at all to read financial information or marketing strategies.=
 So
typically there is not one clearance that can be tied to my identity and a
public key unless the usage of that certificate is limited to one local sys=
tem or
resource where I have a common clearance level for all information within i=
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'>If we go this path, I would not be surprised to see demands =
of
more granular clearance information in certificates where multiple clearanc=
e
level declarations for various different target systems or resources are
stated. This would open up for a whole new set of problems, e.g. how to uni=
formly
name and identify a target system or a limited resource for which this
clearance is relevant. Further if this is to be supported by a path validat=
ion
logic, the algorithm may grow to become very complex.<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"'> [e-mail]
[mailto:[e-mail]] <b>On Behalf Of </b>Stephen Kent<br>
<b>Sent:</b> den 21 februari 2008 19:37<br>
<b>To:</b> [e-mail]<br>
<b>Subject:</b> observations on the Clearance and CA Clearance extension
discussion<o:p></o:p></span></p>

</div>

</div>

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

<div>

<p class=3DMsoNormal><span style=3D'font-size:18.0pt;font-family:Courier;
color:black'>Folks,<br>
<br>
I've been observing this discussion and want to take this opportunity to
summarize what I see as the major issues that have been raised, provide my
perspective on them, and suggest ways to resolve them.<br>
<br>
1. Should we put authorization data of this sort in a PKC vs. an AC?<br>
<br>
ACs were designed to convey authorization data, but PKIX has not prohibited
carrying such data in PKCs. For example, RFC 3779 does so for IP address an=
d AS
number ranges. Since there are precedents&nbsp; in Internet standards for
carriage of authorization data in PKCs this argument need not be revisited.=
<br>
<br>
2. If we carry this data in a PKC, should it be in the SDA extension or be =
a
separate extension?<br>
<br>
Although this is provision for carrying clearance data in the SDA extension=
,
there is an argument for carrying it in a separate extension. In some insta=
nces
(including the ones motivating this I-D) the clearance data may be processe=
d by
high assurance devices/software. In such cases one can argue that having an
extension that carries only this data makes such high assurance processing
easier. One might also argue that in such contexts one would mark this
extension as critical. RFC 3280bis says the SDA extension is always
non-critical, which also argues for creating a separate extension. I assume
that most folks agree that the CA clearance constraints would be a new
extension, a critical one. If the two sets of data are to be processed toge=
ther
in the contexts alluded to above, it seems to make sense that both be new
extensions. A newly assigned OID for a new extension seems appropriate to m=
e.
I'd like to better the motivation to reuse the directory attribute OID here=
,<br>
<br>
3. It's not clear that there is a need to put the CA constraints extension =
in a
self-signed certificate, but it also is not clearly wrong. I can imagine
contexts In which it makes sense to require that the data from this extensi=
on
be present in a certificate path for certificate processing. That seems to
allow three options: have a self-signed certificate representing a TA conta=
in
the extension, have a TA issue a certificate with the extension but not imb=
ed
it in the TA's self-signed certificate, or note that this is an example of
&quot;associated data&quot; for a TA and is used to initialize the certific=
ate
path validation algorithm (as extended to accommodate this data).<br>
<br>
RFC 3779 adopted the first option when it discussed the need to bind the
address space and/or AS number data to a trust anchor. It states that a
certificate serving as a trust anchor MUST contain the extensions that will=
 be
used to constrain instances of the extension in subsequent certificates in =
the
path. So we have a precedent for option #1. However, given our ongoing effo=
rts
to more formally specify the notion associated data for a TA, it makes sens=
e to
consider the third option as well. I'd like to hear arguments about the mer=
its
(and demerits) of all three options, given<br>
<br>
<br>
4. Stefan raised two concerns about putting clearance info in a certificate=
 at
all. Although he didn't say it precisely this way, I note that it is usuall=
y
the case that the authorization of an individual to access classified data
depends not only on the individual's clearance, but also on the (accreditat=
ion
of the) machine being used to access the data, and on the location that mac=
hine
(if it is portable). In my experience it is not appropriate to say that an
individual's clearance changes based on the system he is using, but rather =
that
an individual's authorization usually is constrained by the system he is us=
ing.
I raised a similar issue with a earlier draft, noting that when a certifica=
te
with clearance data is issued to a machine, vs. a person, it is not really =
an
expression of clearance, but of accreditation. The text I the draft needs t=
o
accurately reflect this subtle distinction. Stefan also noted that the
requisite path validation algorithm extensions are non-trivial. If the auth=
ors
want to qualify the intended contexts in which it is expected that the newl=
y
proposed pair of extensions will be used, that might mitigate this concern.=
 The
authors need to address these issues in the text.</span><o:p></o:p></p>

</div>

<div>

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

</div>

</div>

</div>

</body>

</html>

--_000_9F11911AED01D24BAA1C2355723C3D320DE289B663EAEXMSGC332eu_--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M8Ex1I049888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 01:14:59 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1M8ExqF049887; Fri, 22 Feb 2008 01:14: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.13.5/8.13.5) with ESMTP id m1M8Eu4A049878 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 22 Feb 2008 01:14: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.240.5; Fri, 22 Feb 2008 08:14:55 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Fri, 22 Feb 2008 08:14:55 +0000
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, Timothy J Miller <[e-mail]>
CC: "[e-mail]" <[e-mail]>
Date: Fri, 22 Feb 2008 08:14:54 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach00rwQzpN8QWm4T1697TRUfICqvwAU8b/w
Message-ID: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1M8Ew49049882
Sender: [e-mail]
Precedence: 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,

> As an author of RFC 3281, I've made these same arguments to no
> avail.  So, the reason I want to see PKIX take this on it to allow a
> straight forward migration to attribute certificates (because the
> same syntax is used).   If each organization that wants to do this
> does it their own way, we will be much worse off.
>
> Russ

I'm not so sure.

I spent many years of my life as a consultant in government projects of various kinds in Europe and I've seen the kind of impact an RFC like this one can have. A typical scenario is that government agency X in country Y hires an "expert" on PKI that heard of this new standard for how to deal with clearance information, indicating the direction of the industry. This now becomes a fundamental requirement for delivering solutions to this government project which impacts the whole system design. The story ends like a huge number of these projects, that 5-10 years later the users of the targeted information system still uses password based authentication because the high profiled government PKI project crashed under its own weight.

I think I'd much rather see such extension defined within the limited community that think they need it over an international standard with a IETF/PKIX rubber stamp on it. Then of course, if it gets widely deployed, nothing prevents us from endorsing it as an RFC.


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.13.5/8.13.5) with ESMTP id m1M7fqib046475 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 22 Feb 2008 00:41:52 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1M7fqYx046474; Fri, 22 Feb 2008 00:41: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-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M7fmEO046463 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Fri, 22 Feb 2008 00:41:51 -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.240.5; Fri, 22 Feb 2008 07:41:47 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Fri, 22 Feb 2008 07:41:47 +0000
From: Stefan Santesson <[e-mail]>
To: =?iso-8859-1?Q?Philipp_G=FChring?= <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Fri, 22 Feb 2008 07:41:46 +0000
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Thread-Topic: Wildcard DNS. Re: rfc 3280bis
Thread-Index: Ach066th7N+49x1sQq+KgOxwRLd6NQAOMeaA
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[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="iso-8859-1"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1M7fqEN046469
Sender: [e-mail]
Precedence: 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 Philipp,

I see that I failed to get my opinion across:

> So could you please explain to me why you dislike wildcards in DNS
> names?

I don't. In fact I do think it's there because we need it and nobody would be happier than me if we could make the standards reflect this need.
I have also suggested in the past that we make wildcards legal, but I realize that it is controversial and may break previous standards.

Microsoft PKI implementation full out support wildcards in dns names, both in common name and in the dns name field as well as for name constraints processing. We could not remove this support even if we wanted for the reasons you mention.

So to also answer David Cooper. I would not object to a standards track document that updates 3280bis where needed. But if this is not acceptable. An Informational document would be better than nothing. I don't think we should (or can) hold back 3280bis on this matter.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Philipp Gühring
> Sent: den 22 februari 2008 00:51
> To: [e-mail]
> Subject: Re: Wildcard DNS. Re: rfc 3280bis
>
>
> Hi,
>
> > We have only one successful deployment of public certificates, being
> server
> > SSL/TLS certificates. Those using it, issuing certificates for it and
> > developing applications and browsers using it, are not evil people
> with an
> > evil agenda. They simply want to make it work. To make it work, they
> need
> > to take the behavior of others into the calculation which includes
> > interworking with a huge base of existing certificates and
> applications.
>
> Yes.
>
> > Making it work is far more important than being faithful to any
> standard.
> > Sad maybe, but it's a fact of life.
>
> Theoretically, no. Practially, yes.
>
> > This means that no matter how much we may dislike it, the community
> out
> > there will still issue server certificates with dns names in the
> common
> > name field
>
> Ok, I don´t care that much where we put the names, whether it´s the
> common
> name, or SubjectAlternativeNames (couldn´t you find a shorter name for
> it?),
> as long as we can put the name somewhere, and as long as the software
> out
> there actually reads it. (I think that it was forgotten to tell the
> vendors to
> implement SubjectAltnerativeNames somehow. If we want the vendors to
> adhere
> to your standards, we should tell them ...)
>
> > and they will produce certificates with wildcards in the dns
> > name.
>
> I currently see a huge demand on the market for wildcards in
> certificates.
>
> About 7% of the server-certificates that we issued contain wildcards.
> (And we haven´t marketed wildcard certificates or penalted them, so I
> think
> that number somewhat reflects the real demand.)
>
> If I take a look at the whole stack, I see that wildcards are supported
> on all
> layers.
> * DNS  fully supports records like  *.imc.org. IN A 1.2.3.4
> * Webservers  (Apache´s mod_rewrite capabilities are great)
> * Browsers (we have a few interop issues here, but in general it
> works.)
>
> So could you please explain to me why you dislike wildcards in DNS
> names?
>
> > We can simply choose to ignore it or acknowledge it, but we can't
> change
> > it. However we do not have to standardize it.
>
> Due to the huge market demand, I would suggest that it´s being
> standardized
> here.
>
> The only open question I see is whether *.domain.com should match
> sub-subdomains, the domain itself or only subdomains.
> In my personal opinion, this should be consistent with the behaviour of
> the
> DNS, but I would accept any other standard by PKIX too.
>
> From the market perspective, I think the market would accept any
> decision by
> PKIX here. But it´s about time to make that particular decision.
>
> I haven´t found a single vendor yet, that intentionally does not
> support
> wildcards. (And all the major vendors support it anyway. Some even
> support
> Regular Expressions in DNS Names in the certificates *g*)
>
> Wasn´t it the rule that you need 2 independent interoperable
> implementations?
> I think we have more than enough implementations for wildcards now to
> justify
> a standard.
>
> (Or did i misunderstood the dislike, and you prefer some other kind of
> encoding for wildcards? Should it be a Wilcard-DNS-Name in the SAN
> instead of
> using normal DNS-Names in the SAN? Or are you preferring that we use
> RFC4880
> certificates to handle wildcards with TLS servers? )
>
> Best regards,
> Philipp Gühring
>




Received: from [85.121.69.139] ([85.121.69.139]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M6Kp9L040202 for <[e-mail]>; Thu, 21 Feb 2008 23:20:52 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000601c8756f$26ceb600$8b457955@home1a4a212a2e>
From: "Janne Jonker" <[e-mail]>
To: [e-mail]
Subject: Growth and girth is GUARANTEED.
Date: Fri, 22 Feb 2008 08:22:43 -0800
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0002_01C8752C.18AB7600"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0002_01C8752C.18AB7600
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Make love to her longer and harder with this.
----------=_NextPart_000_0002_01C8752C.18AB7600
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.eddiegillie.com/">Make love to her longer and =
harder with=20
this.</A></BODY></HTML>
----------=_NextPart_000_0002_01C8752C.18AB7600--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M69JRN039336 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 23:09:19 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1M69J37039335; Thu, 21 Feb 2008 23:09:19 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp132.iad.emailsrvr.com (smtp132.iad.emailsrvr.com [207.97.245.132]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M69HZp039328 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 23:09:18 -0700 (MST) (envelope-from [e-mail])
Received: from relay3.r3.iad.emailsrvr.com (localhost [127.0.0.1]) by relay3.r3.iad.emailsrvr.com (SMTP Server) with ESMTP id F2B9D44C099 for <[e-mail]>; Fri, 22 Feb 2008 01:09:16 -0500 (EST)
Received: by relay3.r3.iad.emailsrvr.com (Authenticated sender: swilson-AT-lockstep.com.au) with ESMTP id 38D2944C06A for <[e-mail]>; Fri, 22 Feb 2008 01:09:15 -0500 (EST)
Message-ID: <[e-mail]>
Date: Fri, 22 Feb 2008 17:09:15 +1100
From: Stephen Wilson <[e-mail]>
Reply-To: [e-mail]
Organization: Lockstep
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: [e-mail]
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail] osoft.com> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <p0624050ac3e3f5cc544b@[192.168.254.152]>
In-Reply-To: <p0624050ac3e3f5cc544b@[192.168.254.152]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Stephen Kent wrote:

> The cert for my secure phone has always contained clearance info, for 
> 20+ years. It represents both clearance level info and category info. 
> The motivation for this is that the key in the cert is tightly managed, 
> and that is a very expensive management task. To put the clearance info 
> elsewhere would require a separate, expensive management system. As a 
> result, the two are combined.

I agree.  And to generalise, this is why I think Attribute Certificates 
don't often make much sense.  They imply two separate management systems 
when just one would suffice if we relaxed the taboo on "authorisation" 
being blended with "authentication".

Obviously short term clearances and short term 'attributes' in general 
are not such a good fit for X.509 certificates but obviously lots of 
clearances last for years.

> I agree that fine grained clearance info may not be appropriate for 
> certs, but one cannot make a flat statement that such use will not work 
> or will be dangerous. The viability of such use depends on context, and 
> there are lots of different contexts.  You cite multi-year cert 
> lifetimes, but the cert for my phone must be renewed yearly, so that 
> example is not consistent with your cited experience.

Roger that!

Cheers,

Steve Wilson.


Chair, OASIS PKI Adoption TC
Managing Director, Lockstep Group

Phone [phone]

www.lockstep.com.au
-------------------
Lockstep Consulting provides independent specialist advice and analysis 
on identity management, PKI and smartcards.  Lockstep Technologies 
develops unique new smartcard technologies to address transaction 
privacy and web fraud.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1M49VQw029017 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 21:09:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1M49VFm029016; Thu, 21 Feb 2008 21:09:31 -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.13.5/8.13.5) with ESMTP id m1M49UD3029009 for <[e-mail]>; Thu, 21 Feb 2008 21:09:30 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.254.152]) by mx11.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1JSPE1-0008AA-3O; Thu, 21 Feb 2008 23:09:29 -0500
Mime-Version: 1.0
Message-Id: <p0624050ac3e3f5cc544b@[192.168.254.152]>
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail] osoft.com> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Feb 2008 23:09:28 -0500
To: Timothy J Miller <[e-mail]>
From: Stephen Kent <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: Russ Housley <[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>

Tim,

The cert for my secure phone has always contained clearance info, for 
20+ years. It represents both clearance level info and category info. 
The motivation for this is that the key in the cert is tightly 
managed, and that is a very expensive management task. To put the 
clearance info elsewhere would require a separate, expensive 
management system. As a result, the two are combined.

I agree that fine grained clearance info may not be appropriate for 
certs, but one cannot make a flat statement that such use will not 
work or will be dangerous. The viability of such use depends on 
context, and there are lots of different contexts.  You cite 
multi-year cert lifetimes, but the cert for my phone must be renewed 
yearly, so that example is not consistent with your cited experience.

My experience is that many folks are granted access to major 
categories for very long intervals, so even above the collateral 
level info there is value in being able to express this clearance 
info in certs.

Your comment about who issues certs/badge vs. clearance management is 
simply not uniformly true. Maybe you're comments are based on 
experience with the CAC and software certs issued by DISA; you didn't 
say.  The CAC is a poster boy for a badly designed PKI, in numerous 
ways, so I would not use it as good model (for almost anything).

I am familiar with examples of certs issued in DoD under other 
paradigms, which are not consistent with many of your observations. 
SO I think it's fair to say that while it may not always be a good 
idea to put clearance info into PKCs, it is not true that it is never 
a god idea.

Steve




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LNokYW008754 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:50:46 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LNokJJ008753; Thu, 21 Feb 2008 16:50:46 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mailbox.go-now.at (dns4.go-now.at [62.99.220.146]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LNoiTu008743 for <[e-mail]>; Thu, 21 Feb 2008 16:50:45 -0700 (MST) (envelope-from [e-mail])
Received: from philippslaptop.lan M2429P018.adsl.highway.telekom.at  (authenticated user [e-mail]) by mailbox.go-now.at (MDaemon.PRO.v6.8.5.R) with ESMTP id 48-md50000000032.tmp for <[e-mail]>; Fri, 22 Feb 2008 00:50:37 +0100
From: Philipp =?iso-8859-1?q?G=FChring?= <[e-mail]>
Organization: Futureware 2001
To: "[e-mail]" <[e-mail]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Date: Fri, 22 Feb 2008 00:50:33 +0100
User-Agent: KMail/1.9.1
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[e-mail]>
In-Reply-To: <[e-mail]>
MIME-Version: 1.0
Content-Disposition: inline
Content-Type: text/plain; charset="iso-8859-1"
Message-Id: <[e-mail]>
X-Authenticated-Sender: [e-mail]
X-Spam-Processed: mailbox.go-now.at, Fri, 22 Feb 2008 00:50:37 +0100 (not processed: spam filter disabled)
X-Return-Path: [e-mail]
X-MDaemon-Deliver-To: [e-mail]
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LNokTu008748
Sender: [e-mail]
Precedence: 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,

> We have only one successful deployment of public certificates, being server
> SSL/TLS certificates. Those using it, issuing certificates for it and
> developing applications and browsers using it, are not evil people with an
> evil agenda. They simply want to make it work. To make it work, they need
> to take the behavior of others into the calculation which includes
> interworking with a huge base of existing certificates and applications.

Yes.

> Making it work is far more important than being faithful to any standard.
> Sad maybe, but it's a fact of life.

Theoretically, no. Practially, yes.

> This means that no matter how much we may dislike it, the community out
> there will still issue server certificates with dns names in the common
> name field 

Ok, I don´t care that much where we put the names, whether it´s the common 
name, or SubjectAlternativeNames (couldn´t you find a shorter name for it?), 
as long as we can put the name somewhere, and as long as the software out 
there actually reads it. (I think that it was forgotten to tell the vendors to 
implement SubjectAltnerativeNames somehow. If we want the vendors to adhere 
to your standards, we should tell them ...)

> and they will produce certificates with wildcards in the dns 
> name.

I currently see a huge demand on the market for wildcards in certificates.

About 7% of the server-certificates that we issued contain wildcards.
(And we haven´t marketed wildcard certificates or penalted them, so I think 
that number somewhat reflects the real demand.)

If I take a look at the whole stack, I see that wildcards are supported on all 
layers.
* DNS  fully supports records like  *.imc.org. IN A 1.2.3.4
* Webservers  (Apache´s mod_rewrite capabilities are great)
* Browsers (we have a few interop issues here, but in general it works.)

So could you please explain to me why you dislike wildcards in DNS names?

> We can simply choose to ignore it or acknowledge it, but we can't change
> it. However we do not have to standardize it.

Due to the huge market demand, I would suggest that it´s being standardized 
here.

The only open question I see is whether *.domain.com should match 
sub-subdomains, the domain itself or only subdomains.
In my personal opinion, this should be consistent with the behaviour of the 
DNS, but I would accept any other standard by PKIX too.

>From the market perspective, I think the market would accept any decision by 
PKIX here. But it´s about time to make that particular decision.

I haven´t found a single vendor yet, that intentionally does not support 
wildcards. (And all the major vendors support it anyway. Some even support 
Regular Expressions in DNS Names in the certificates *g*)

Wasn´t it the rule that you need 2 independent interoperable implementations?
I think we have more than enough implementations for wildcards now to justify 
a standard.

(Or did i misunderstood the dislike, and you prefer some other kind of 
encoding for wildcards? Should it be a Wilcard-DNS-Name in the SAN instead of 
using normal DNS-Names in the SAN? Or are you preferring that we use RFC4880 
certificates to handle wildcards with TLS servers? )

Best regards,
Philipp Gühring




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LNjWQ0008292 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:45:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LNjWBH008291; Thu, 21 Feb 2008 16: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 smtp-dub.microsoft.com (smtp-dub.microsoft.com [213.199.138.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LNjUJA008282 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 16:45:31 -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.240.5; Thu, 21 Feb 2008 23:45:29 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 21 Feb 2008 23:45:29 +0000
From: Stefan Santesson <[e-mail]>
To: Timothy J Miller <[e-mail]>, Santosh Chokhani <[e-mail]>
CC: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 21 Feb 2008 23:45:28 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0xiAfxXgINf2jQweM1r51/iCXMAAHO32A
Message-ID: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LNjWJ9008285
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

> > So, I have the following question for you: Do you have a better
> > suggestion to meet the needs to communities that need to process
> > clearances in secure manner?
>
> Yes, I do.  Invest in an identity management system and an
> *authorization* framework.  You'll be better off.
>
> -- Tim

I really support this view. About everything I have seen and experienced in this space indicates that this is true.
What I think we need is not a more complex and harder to manage PKI, but rather to consolidate PKI to its core function to assert a relationship between an entity and a key.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: Timothy J Miller [mailto:[e-mail]]
> Sent: den 21 februari 2008 21:12
> To: Santosh Chokhani
> Cc: Stefan Santesson; Russ Housley; [e-mail]
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
> On Feb 21, 2008, at 11:16 AM, Santosh Chokhani wrote:
>
> > Let us look at the issue of clearance in a certificate first.  The
> > reason to include the clearance in a certificate is that in many
> > environments clearance is relatively static.
>
> Only at its lowest and grossest levels.  At higher levels, frex above
> US TS, special program accesses can be very dynamic--particularly
> over the multi-year lifetime of a user certificate.
>
> My particular objection is that by implication you are relying on the
> *revocation* infrastructure to control access to materials based on
> clearance.  This is unwise.  Revocation is neither guaranteed nor
> timely in real-world PKIs--particularly large ones.  Access is better
> controlled by, well, access control systems.
>
> > Also, asserting clearance
> > in certificates is appropriate since security office who knows or
> > holds
> > personnel clearances also is involved in issuing certificates.
>
> This is not true everywhere.  DoD certificates are managed by
> personnel offices, not security.
>
> > Finally,
> > putting them in certificates and vetting them provides a cost-
> > effective
> > binding.
>
> So do attribute certs.  However, you're also overlooking the hidden
> costs caused by additionally burdening the revocation infrastructure--
> because if you're using a clearance extension I *guarantee* you'll
> end up doing more revocations.
>
> > So, I have the following question for you: Do you have a better
> > suggestion to meet the needs to communities that need to process
> > clearances in secure manner?
>
> Yes, I do.  Invest in an identity management system and an
> *authorization* framework.  You'll be better off.
>
> -- Tim




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LNEwKP005413 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:14:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LNEwv4005412; Thu, 21 Feb 2008 16:14:58 -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.162] (adsl-66-125-125-65.dsl.pltn13.pacbell.net [66.125.125.65]) (authenticated bits=0) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LNEsig005399 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:14:55 -0700 (MST) (envelope-from [e-mail])
Mime-Version: 1.0
Message-Id: <p06240812c3e3b5556aa5@[10.20.30.162]>
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail] osoft.com> <[e-mail]> <[e-mail]> <[e-mail]>
Date: Thu, 21 Feb 2008 15:14:52 -0800
To: [e-mail]
From: Paul Hoffman <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: Russ Housley <[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:48 PM -0500 2/21/08, Russ Housley wrote:
>I believe that this is all still correct.  Yet, there are people 
>that want to put clearance information into public key certificates. 
>It is important to me that the syntax for representing the clearance 
>in a certificate and an attribute certificate are exactly the same. 
>RFC 3281 already specifies it for an attribute certificate.  There 
>are folks who are going to put clearance information in a 
>certificate.  I'd like them all to do it the same way, so that when 
>policy permits, they can interoperate.

Sure. But shouldn't the specification also give the reader sharp 
warnings about both the problems associated with doing so, and 
pointers to ways that we think are better? I see nothing about this 
in the intro of the draft; it is also absent from the Security 
Considerations.

>As an author of RFC 3281, I've made these same arguments to no 
>avail.  So, the reason I want to see PKIX take this on it to allow a 
>straight forward migration to attribute certificates (because the 
>same syntax is used).   If each organization that wants to do this 
>does it their own way, we will be much worse off.

But if other organizations read this document and think it is a good 
idea, *they* will be worse off. It seems short-sighted for all of us 
on this list to know that attributes certs are better suited for 
this, but the document be silent about that.

--Paul Hoffman, Director
--VPN Consortium



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LN4Xut004150 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 16:04:33 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LN4XsK004147; Thu, 21 Feb 2008 16:04:33 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from mx12.bbn.com (mx12.bbn.com [128.33.0.81]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LN4T8M004135 for <[e-mail]>; Thu, 21 Feb 2008 16:04:29 -0700 (MST) (envelope-from [e-mail])
Received: from dommiel.bbn.com ([192.1.122.15] helo=[192.168.254.152]) by mx12.bbn.com with esmtp (Exim 4.60) (envelope-from <[e-mail]>) id 1JSKSo-00067B-4a for [e-mail]; Thu, 21 Feb 2008 18:04:28 -0500
Mime-Version: 1.0
Message-Id: <p06240500c3e366ef69eb@[128.89.89.71]>
Date: Thu, 21 Feb 2008 13:36:36 -0500
To: [e-mail]
From: Stephen Kent <[e-mail]>
Subject: observations on the Clearance and CA Clearance extension discussion
Content-Type: multipart/alternative; boundary="============_-1008487423==_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>

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

Folks,

I've been observing this discussion and want to take this opportunity 
to summarize what I see as the major issues that have been raised, 
provide my perspective on them, and suggest ways to resolve them.

1. Should we put authorization data of this sort in a PKC vs. an AC?

ACs were designed to convey authorization data, but PKIX has not 
prohibited carrying such data in PKCs. For example, RFC 3779 does so 
for IP address and AS number ranges. Since there are precedents  in 
Internet standards for carriage of authorization data in PKCs this 
argument need not be revisited.

2. If we carry this data in a PKC, should it be in the SDA extension 
or be a separate extension?

Although this is provision for carrying clearance data in the SDA 
extension, there is an argument for carrying it in a separate 
extension. In some instances (including the ones motivating this I-D) 
the clearance data may be processed by high assurance 
devices/software. In such cases one can argue that having an 
extension that carries only this data makes such high assurance 
processing easier. One might also argue that in such contexts one 
would mark this extension as critical. RFC 3280bis says the SDA 
extension is always non-critical, which also argues for creating a 
separate extension. I assume that most folks agree that the CA 
clearance constraints would be a new extension, a critical one. If 
the two sets of data are to be processed together in the contexts 
alluded to above, it seems to make sense that both be new extensions. 
A newly assigned OID for a new extension seems appropriate to me. I'd 
like to better the motivation to reuse the directory attribute OID 
here,

3. It's not clear that there is a need to put the CA constraints 
extension in a self-signed certificate, but it also is not clearly 
wrong. I can imagine contexts In which it makes sense to require that 
the data from this extension be present in a certificate path for 
certificate processing. That seems to allow three options: have a 
self-signed certificate representing a TA contain the extension, have 
a TA issue a certificate with the extension but not imbed it in the 
TA's self-signed certificate, or note that this is an example of 
"associated data" for a TA and is used to initialize the certificate 
path validation algorithm (as extended to accommodate this data).

RFC 3779 adopted the first option when it discussed the need to bind 
the address space and/or AS number data to a trust anchor. It states 
that a certificate serving as a trust anchor MUST contain the 
extensions that will be used to constrain instances of the extension 
in subsequent certificates in the path. So we have a precedent for 
option #1. However, given our ongoing efforts to more formally 
specify the notion associated data for a TA, it makes sense to 
consider the third option as well. I'd like to hear arguments about 
the merits (and demerits) of all three options, given


4. Stefan raised two concerns about putting clearance info in a 
certificate at all. Although he didn't say it precisely this way, I 
note that it is usually the case that the authorization of an 
individual to access classified data depends not only on the 
individual's clearance, but also on the (accreditation of the) 
machine being used to access the data, and on the location that 
machine (if it is portable). In my experience it is not appropriate 
to say that an individual's clearance changes based on the system he 
is using, but rather that an individual's authorization usually is 
constrained by the system he is using. I raised a similar issue with 
a earlier draft, noting that when a certificate with clearance data 
is issued to a machine, vs. a person, it is not really an expression 
of clearance, but of accreditation. The text I the draft needs to 
accurately reflect this subtle distinction. Stefan also noted that 
the requisite path validation algorithm extensions are non-trivial. 
If the authors want to qualify the intended contexts in which it is 
expected that the newly proposed pair of extensions will be used, 
that might mitigate this concern. The authors need to address these 
issues in the text.

--============_-1008487423==_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>observations on the Clearance and CA Clearance
extension d</title></head><body>
<div><font face="Courier" size="+2" color="#000000">Folks,<br>
<br>
I've been observing this discussion and want to take this opportunity
to summarize what I see as the major issues that have been raised,
provide my perspective on them, and suggest ways to resolve them.<br>
<br>
1. Should we put authorization data of this sort in a PKC vs. an
AC?<br>
<br>
ACs were designed to convey authorization data, but PKIX has not
prohibited carrying such data in PKCs. For example, RFC 3779 does so
for IP address and AS number ranges. Since there are precedents&nbsp;
in Internet standards for carriage of authorization data in PKCs this
argument need not be revisited.<br>
<br>
2. If we carry this data in a PKC, should it be in the SDA extension
or be a separate extension?<br>
<br>
Although this is provision for carrying clearance data in the SDA
extension, there is an argument for carrying it in a separate
extension. In some instances (including the ones motivating this I-D)
the clearance data may be processed by high assurance
devices/software. In such cases one can argue that having an extension
that carries only this data makes such high assurance processing
easier. One might also argue that in such contexts one would mark this
extension as critical. RFC 3280bis says the SDA extension is always
non-critical, which also argues for creating a separate extension. I
assume that most folks agree that the CA clearance constraints would
be a new extension, a critical one. If the two sets of data are to be
processed together in the contexts alluded to above, it seems to make
sense that both be new extensions. A newly assigned OID for a new
extension seems appropriate to me. I'd like to better the motivation
to reuse the directory attribute OID here,<br>
<br>
3. It's not clear that there is a need to put the CA constraints
extension in a self-signed certificate, but it also is not clearly
wrong. I can imagine contexts In which it makes sense to require that
the data from this extension be present in a certificate path for
certificate processing. That seems to allow three options: have a
self-signed certificate representing a TA contain the extension, have
a TA issue a certificate with the extension but not imbed it in the
TA's self-signed certificate, or note that this is an example of
"associated data" for a TA and is used to initialize the certificate
path validation algorithm (as extended to accommodate this data).<br>
<br>
RFC 3779 adopted the first option when it discussed the need to bind
the address space and/or AS number data to a trust anchor. It states
that a certificate serving as a trust anchor MUST contain the
extensions that will be used to constrain instances of the extension
in subsequent certificates in the path. So we have a precedent for
option #1. However, given our ongoing efforts to more formally specify
the notion associated data for a TA, it makes sense to consider the
third option as well. I'd like to hear arguments about the merits (and
demerits) of all three options, given<br>
<br>
<br>
4. Stefan raised two concerns about putting clearance info in a
certificate at all. Although he didn't say it precisely this way, I
note that it is usually the case that the authorization of an
individual to access classified data depends not only on the
individual's clearance, but also on the (accreditation of the) machine
being used to access the data, and on the location that machine (if it
is portable). In my experience it is not appropriate to say that an
individual's clearance changes based on the system he is using, but
rather that an individual's authorization usually is constrained by
the system he is using. I raised a similar issue with a earlier draft,
noting that when a certificate with clearance data is issued to a
machine, vs. a person, it is not really an expression of clearance,
but of accreditation. The text I the draft needs to accurately reflect
this subtle distinction. Stefan also noted that the requisite path
validation algorithm extensions are non-trivial. If the authors want
to qualify the intended contexts in which it is expected that the
newly proposed pair of extensions will be used, that might mitigate
this concern. The authors need to address these issues in the
text.</font></div>
<div><font face="Courier" size="+2" color="#000000"><br></font></div>
</body>
</html>
--============_-1008487423==_ma============--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LMc7dj001337 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 15:38:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LMc75A001336; Thu, 21 Feb 2008 15:38:07 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LMc616001326 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 15:38:07 -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 m1LMc1oa026855; Thu, 21 Feb 2008 17:38:01 -0500
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 m1LMbwUY004661; Thu, 21 Feb 2008 17:37:58 -0500
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 17:37:51 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20080213)
MIME-Version: 1.0
To: Russ Housley <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-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>

Russ Housley wrote:
> It is important to me that the syntax for representing the clearance 
> in a certificate and an attribute certificate are exactly the same.  
> RFC 3281 already specifies it for an attribute certificate.  There are 
> folks who are going to put clearance information in a certificate.  
> I'd like them all to do it the same way, so that when policy permits, 
> they can interoperate.

Unfortunately, the current draft is working against this goal.  There is 
already a mechanism defined in X.501 including clearance information in 
a public key certificate.  X.501 defines the clearance attribute, which 
(as X.501 notes) would be placed in the subjectDirectoryAttributes 
extension when included in a public key certificate.  This draft defines 
a new certificate extension that uses the syntax and OID of the X.501 
clearance attribute.  Thus, there will be two ways defined for CAs to 
include clearance information in public key certificates, even though 
both use the same syntax.  If the goal is for everyone to encode this 
information in public key certificates in the same way, then we 
shouldn't base achieving that goal on the assumption that everyone will 
ignore X.501 when determining how to encode an X.501 defined attribute.

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LLDwmq094138 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:13:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LLDwdS094137; Thu, 21 Feb 2008 14:13: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-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LLDusV094131 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 14:13:57 -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 m1LLDtrX014319 for <[e-mail]>; Thu, 21 Feb 2008 16:13:56 -0500
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1LLDtBf014311; Thu, 21 Feb 2008 16:13:55 -0500
Received: from [208.54.136.177] ([172.31.6.26]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 16:13:54 -0500
In-Reply-To: <00ba01c874cb$0d38aba0$0301a8c0@Wylie>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <00ba01c874cb$0d38aba0$0301a8c0@Wylie>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-8--164589378; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: "'Santosh Chokhani'" <[e-mail]>, "'Stefan Santesson'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, <[e-mail]>
From: Timothy J Miller <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 15:13:13 -0600
To: "Turner, Sean P." <[e-mail]>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 21 Feb 2008 21:13:55.0073 (UTC) FILETIME=[AA628F10:01C874CE]
Sender: [e-mail]
Precedence: 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-8--164589378
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Feb 21, 2008, at 2:48 PM, Turner, Sean P. wrote:

> The access control system is still in control of access.  The  
> output of the
> path processing is the subject's clearances not an access control  
> decision.
> The output of the path processing can be passed to the access  
> control system
> to make it's decision.

Through this binding you're tying the validity assurance of clearance  
data to the validity assurance of the certificate.  I'd assert that  
generally speaking you want/need *higher* validity assurance of  
clearance.  Yes, this can vary by environment, but I'm willing to bet  
that this would be generally true.

However, as Russ so gently pointed out, discussing the "why" of this  
is off-topic.

-- Tim


--Apple-Mail-8--164589378
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjIxMjExMzE0
WjAjBgkqhkiG9w0BCQQxFgQUPeqfPWkQE1PVT58ZkK38vkd+kSMwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYBJow8uCv8LcCbXKJFQscAnDpY6pnb+qmD5SNDSmX2PEUoLWn1LGFQO5gvUpWqW9TkCfMT3
d/hyifFTpa8ORixfEsag/l0Q9rXatLoWzGmA4R199vAcFPJUTL99NOja6ecc0lDePUXmsbekS3Ev
3bILf8oWQatPU3+bt13dNsXoogAAAAAAAA==

--Apple-Mail-8--164589378--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LL8iMX093561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:08:44 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LL8iSD093560; Thu, 21 Feb 2008 14:08:44 -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.13.5/8.13.5) with ESMTP id m1LL8heK093551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 14:08:43 -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 m1LL8g9E032568 for <[e-mail]>; Thu, 21 Feb 2008 16:08:42 -0500
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1LL8gAT032564; Thu, 21 Feb 2008 16:08:42 -0500
Received: from [208.54.136.177] ([172.31.6.26]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 16:08:40 -0500
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-7--164900811; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: [e-mail]
From: Timothy J Miller <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 15:07:53 -0600
To: Russ Housley <[e-mail]>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 21 Feb 2008 21:08:41.0851 (UTC) FILETIME=[EFB0ACB0:01C874CD]
Sender: [e-mail]
Precedence: 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-7--164900811
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Feb 21, 2008, at 2:48 PM, Russ Housley wrote:

> I believe that this is all still correct.  Yet, there are people  
> that want to put clearance information into public key  
> certificates.  It is important to me that the syntax for  
> representing the clearance in a certificate and an attribute  
> certificate are exactly the same.  RFC 3281 already specifies it  
> for an attribute certificate.  There are folks who are going to put  
> clearance information in a certificate.  I'd like them all to do it  
> the same way, so that when policy permits, they can interoperate.

[...]

> As an author of RFC 3281, I've made these same arguments to no  
> avail.  So, the reason I want to see PKIX take this on it to allow  
> a straight forward migration to attribute certificates (because the  
> same syntax is used).   If each organization that wants to do this  
> does it their own way, we will be much worse off.

Then we agree.  :)

I should have been clearer; I wasn't questioning the method, I was  
questioning the motive.  I'm dead-set against contaminating my  
authentication instrument with authorization data.  But if that's  
something someone wants to do--misguided though it may be--then any  
method that provides a clear path from authN-cum-authZ cert to  
attribute cert is the best way to go.

-- Tim
--Apple-Mail-7--164900811
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjIxMjEwNzU0
WjAjBgkqhkiG9w0BCQQxFgQU57HxCfxiIaVthtQTFhZ77yywY+EwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYBaouMI8SteXkRz6wu1V1DqxCwJ8Xgpc/M8CWcL8zxR4aGmRLWMMjfuuBWc1l+m7Y91/sVC
bjpxL73HyuqtI93tpsIs2jejYYONway04twOpWsUGfX46cqQ1wAa15Ned/S4pRpSpB5uf5vvI9Bo
GS+wcFIraL0MPcDENh2aCisSkQAAAAAAAA==

--Apple-Mail-7--164900811--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LL7oQd093495 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 14:07:50 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LL7ooe093494; Thu, 21 Feb 2008 14:07:50 -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.13.5/8.13.5) with SMTP id m1LL7nQW093488 for <[e-mail]>; Thu, 21 Feb 2008 14:07:49 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 31197 invoked from network); 21 Feb 2008 21:00:14 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 21:00:14 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 21:00:13 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 16:07:47 -0500
Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_00A4_01C874A3.E64B3980"
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0xh1TzDfAmLsVSo+6MWtbChT64QABcQKQ
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Timothy J Miller" <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "Russ Housley" <[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_000_00A4_01C874A3.E64B3980
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit

Tim,

See responses in-line.

-----Original Message-----
From: Timothy J Miller [mailto:[e-mail]] 
Sent: Thursday, February 21, 2008 3:12 PM
To: Santosh Chokhani
Cc: Stefan Santesson; Russ Housley; [e-mail]
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

On Feb 21, 2008, at 11:16 AM, Santosh Chokhani wrote:

> Let us look at the issue of clearance in a certificate first.  The
> reason to include the clearance in a certificate is that in many
> environments clearance is relatively static.

Only at its lowest and grossest levels.  At higher levels, frex above  
US TS, special program accesses can be very dynamic--particularly  
over the multi-year lifetime of a user certificate.
[Santosh] Some of the scenarios we have in mind, the certificates themselves
may be shorter life time than you stipulate.

My particular objection is that by implication you are relying on the  
*revocation* infrastructure to control access to materials based on  
clearance.  This is unwise.  Revocation is neither guaranteed nor  
timely in real-world PKIs--particularly large ones.  Access is better  
controlled by, well, access control systems.
[Santosh] If multiple relying parties rely on an attribute, in a distributed
framework, it is better to have the bestowing authority revoke the
attribute.  If a particular relying party is concerned about an attribute,
it can have its additional checks.  It is equally unwise to assume that
revocation of an attribute will be carried out by multiple relying parties
properly.

[Santosh] A better solution may be SAML authorization assertions.  However,
in that scenario the SAML Authorization Server is the one that implements
what this I-D says.

> Also, asserting clearance
> in certificates is appropriate since security office who knows or  
> holds
> personnel clearances also is involved in issuing certificates.

This is not true everywhere.  DoD certificates are managed by  
personnel offices, not security.
[Santosh] In many environments, badging and security go hand in hand and
that is where credentials are issued.

> Finally,
> putting them in certificates and vetting them provides a cost- 
> effective
> binding.

So do attribute certs.  However, you're also overlooking the hidden  
costs caused by additionally burdening the revocation infrastructure-- 
because if you're using a clearance extension I *guarantee* you'll  
end up doing more revocations.
[Santosh] That is simply a cost trade off.  BTW, AC do not mitigate the
revocation problem.

> So, I have the following question for you: Do you have a better
> suggestion to meet the needs to communities that need to process
> clearances in secure manner?

Yes, I do.  Invest in an identity management system and an  
*authorization* framework.  You'll be better off.
[Santosh] We have several tools such as local access control, attribute
certificates, SDA in PKC, SAML Authorization Servers (which can work from
AC, PKC or local knowledge).  Saying one shoe fits all is wrong.

[Santosh]Besides, this I-D provides processing rules for hierarchical,
distributed environments.  Authorization determination engine implementation
location will determine where this logic goes.  So, if you had SAML Servers
or local decision makers (based on objects created by distributed
authorities), that the processing rules will be implemented there.

-- Tim


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

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIILVjCCA60w
ggKVoAMCAQICBECEF1YwDQYJKoZIhvcNAQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5
Z25hY29tMB4XDTA0MDQxOTE3NDYwMVoXDTI0MDQxOTE4MTYwMVowIDELMAkGA1UEBhMCdXMxETAP
BgNVBAoTCGN5Z25hY29tMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAuw8jjNSH/3qx
UShITC4+vYJG8TZsE2f4pbGUhcXe+v0PChxtWvVpOAVqXm/7y1hdBKKMjdg98Xo/jmVtFPGlKXhV
v9FYyK1zxydN1YgEjRzmuSd9RNNm9YL2rgg2Q/TtT3hDwDiT4rj62ukIKYTlZHNLm1t7uYa8K/44
F5jJvo6zPkWtRqrKBFJfBblKFaPteEXU5JIKX8cbwIF3HJx9+P15S0wRngCKb0+1/d9pIuwS4Frg
1R98hG+jRXiS8klB6TncucWH2w1OqYouzUGSncb+o+EVx4PHwsE7kKxIMAsQC6zbHsAS0CAOb6hw
JW7P+dtaR/9Gi8NdKsgkFlQjbQIDAQABo4HuMIHrMEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYD
VQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTALBgNVBAMTBENSTDEwKwYDVR0QBCQwIoAPMjAw
NDA0MTkxNzQ2MDFagQ8yMDI0MDQxOTE4MTYwMVowCwYDVR0PBAQDAgEGMB8GA1UdIwQYMBaAFHqT
o3DI3p2/kOS+O6DeN/DUalp5MB0GA1UdDgQWBBR6k6NwyN6dv5Dkvjug3jfw1GpaeTAMBgNVHRME
BTADAQH/MB0GCSqGSIb2fQdBAAQQMA4bCFY3LjA6NC4wAwIEkDANBgkqhkiG9w0BAQUFAAOCAQEA
aHtrFA6rDnATj2GxfNuRLFVrsWBLSCYUdMs6YbssKI2f/Fh/o382eAnvvcpI76koLijn4Cbj482A
tkWgw6hOhgESamFWaY951O0nUrk43KG5Nv4KQjXiNArFwf1ATEtB6KTeiaffh2vVbUWodZ+uwnTh
X6ZlPmVooWFcB9NH+9GteR7zIJA/Eq0p0CHiCozIhOp1QGJ2cXTtHQk4Cq+sYh8du6ry0xRB3b5Z
Jw/iewtxAoge2e/vh0f46mgrSdmCuPzjVLvyLg63ktN9hJe8Iiy4JiKqplnsMGizW2lxKwl/Ys0L
alsltxYuLF1jytrzGJEit+5acGcjhdhijL0IojCCA7cwggKfoAMCAQICBECEfaYwDQYJKoZIhvcN
AQEFBQAwIDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMB4XDTA4MDIwNDE5MzE1N1oX
DTExMDIwNDIwMDE1N1owOzELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tMRkwFwYDVQQD
ExBTYW50b3NoIENob2toYW5pMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAs9o3aeGJ
DZDK4g4sEFFK6w+OkEcGHDQjYRCIuqh7uC3mVnPAk3lyUaRoVXJtZw3w8kD0XVbSH86u090X60cP
zAtgW4irh9vEKQ/B2ze/D9DHjNp6y5t3Eq/LyPYLPFFivWfccVygX0ufdgJ37z2lXZhg+mVIms48
PxBOtRWGH66wNc75+NkmpRDgi4byKUOKcfy8Fm52lUrnN4GEuv/fFBSBQAWdbafCHbuDJp/KZMEX
lEqnQ1GemkuAbMmj37dcP5Vw57UQlF2LILXswfmTH2JQdqTXz635HlPfJQS9yuX/MP+upkPGRToy
RMFrufttu7M3mmPofNW7kFgT0jL+eQIDAQABo4HdMIHaMCEGA1UdEQQaMBiBFnNjaG9raGFuaUBj
eWduYWNvbS5jb20wQgYDVR0fBDswOTA3oDWgM6QxMC8xCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhj
eWduYWNvbTENMAsGA1UEAxMEQ1JMMTALBgNVHQ8EBAMCBSAwHwYDVR0jBBgwFoAUepOjcMjenb+Q
5L47oN438NRqWnkwHQYDVR0OBBYEFN3Oy0J5Tcq3swE9ftXJsWLGkP/RMAkGA1UdEwQCMAAwGQYJ
KoZIhvZ9B0EABAwwChsEVjcuMAMCBJAwDQYJKoZIhvcNAQEFBQADggEBABhU71iFvfdyRs+fo+it
Pum3CUTu4aufARo9Rva+r/fmeBFyFc/jryqFtqoqS17dATYAgjr/7Yk12g72o4TsKN5ganteAM2r
r61E5+4h2ucGHLfWykqZtKg2w84n5wbIGXG6PgAaFxk9KwbQEhcHKGRESN9HszXdonYBjMwQLqb2
VSzP+PDD0ACSHPlaL4KdaQ+pnUtdmHpTK1Yr0HoxQ6vc8xXdKQvFV6xmrAJBDGFkHf5INrkSBMhP
W1xf+ogv94VptXt0DLW06mhvkp3sniARXFFWKFfPxqsLAsmR2c/uJfr4zjSi4t2h6L41NgeM5+AN
ezuwuorXARAk+uaOC5MwggPmMIICzqADAgECAgRAhH2oMA0GCSqGSIb3DQEBBQUAMCAxCzAJBgNV
BAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbTAeFw0wODAyMDQxOTM1NTlaFw0xMTAyMDQyMDA1NTla
MDsxCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbTEZMBcGA1UEAxMQU2FudG9zaCBDaG9r
aGFuaTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAJ1rEVGyPcyt6QIby/uVXD9cMpBF
wYLQjOM6dNXMzQIEUXRtcT0W8tC41xHPKyFLWAp9FYz6S8bLV59/M0+yi+fTRFvz0Nzpp8Gl4XZD
xE5oucsywODMnZUnPyEjasL6v02CDu5Q4MEGNu0Wg1VeryppZrK2IZ0BEwK1Of2bgLWkPfbJuflS
9QOAMwKhSpJ6rb1o8WCqms6CC3Y9hf3HG7yYfc8k7gievsnZhSUWTOChPul963Q4qLxvC6MDxF2O
kM+bnGW5WY7EpneZAsM8K/B/8VTg8YnBcQJdVrhQkoBMhJc7m3YPU3zGFpjhjzWDL3nHsxSSw85O
QI52kMxU1J0CAwEAAaOCAQswggEHMAsGA1UdDwQEAwIHgDArBgNVHRAEJDAigA8yMDA4MDIwNDE5
MzU1OVqBDzIwMTAwMzEzMDAwNTU5WjAhBgNVHREEGjAYgRZzY2hva2hhbmlAY3lnbmFjb20uY29t
MEIGA1UdHwQ7MDkwN6A1oDOkMTAvMQswCQYDVQQGEwJ1czERMA8GA1UEChMIY3lnbmFjb20xDTAL
BgNVBAMTBENSTDEwHwYDVR0jBBgwFoAUepOjcMjenb+Q5L47oN438NRqWnkwHQYDVR0OBBYEFMpd
jcqM0dS0T98qfQfCqOQmoEhLMAkGA1UdEwQCMAAwGQYJKoZIhvZ9B0EABAwwChsEVjcuMAMCBLAw
DQYJKoZIhvcNAQEFBQADggEBAA/ZNrruYd642E8uMJ1EIDbQNsbPuNO7KXZpTcRT9DxntFCfMFkR
hnIZDETqQaIVtCCMRd0kOk+rf8PCYhyqybY0S/fovU3zW3LIVLICCN01CgUpQwejJxVsGFBVPdtK
AwOHneG99t6Etr2NuWCGKR6Z4pRtYjLsI80NoZz8pC5WnjFuClbse5S/PQ1L9PhdLTS/xk2bn/Rx
+wYMamRki4Ec6Wgu47ud3JfmNhrmmN5TuGocHG7XwS6JtXb3wG0qcXlzg8sNlqk1doswxsMTQHUt
eqK8JASKjmkIl5MusXaZRvSD6DJQzkQxpJeEujTsUrPUtCHVHoYmQGKseTEc8CkxggKNMIICiQIB
ATAoMCAxCzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbQIEQIR9qDAJBgUrDgMCGgUAoIIB
OjAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wODAyMjEyMTA3NDda
MCMGCSqGSIb3DQEJBDEWBBRavPPyBu3HsRT6SGdpEdF5hgQCjjA3BgkrBgEEAYI3EAQxKjAoMCAx
CzAJBgNVBAYTAnVzMREwDwYDVQQKEwhjeWduYWNvbQIEQIR9pjA5BgsqhkiG9w0BCRACCzEqoCgw
IDELMAkGA1UEBhMCdXMxETAPBgNVBAoTCGN5Z25hY29tAgRAhH2mMGcGCSqGSIb3DQEJDzFaMFgw
CgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFAMAcGBSsOAwIHMA0GCCqG
SIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMA0GCSqGSIb3DQEBAQUABIIBAHFBYboTUat8
+BhQJlygrQYV780wyYoED4nnVQ5hUnavHj/cJT2OB2IVqxD4yjcfBOUEKjJjByiE2M15AjxhoetV
KkK+VClv8FkJEAISfgSDeUmBD+6kSSceDqMWNI7lLq6eohI2bRr43hJZNzLsxvya9bp/FtDSL9AL
UK6VttH0qZ05lK89nOm+iLJdE6wXCo6ZvDAxD8379RfxpazhcI6vqNB5dztCYxsxdq2FTc4dedBw
8MHI4sQJqSm9nkxHvnlMavicIbe0vxNviDrpIvnKpmsv4gWQ7yMPAKdGjwidRhBslbuzf1yEeI08
mfkpqgT9uxrEjmgg3bX+wHBxkUEAAAAAAAA=

------=_NextPart_000_00A4_01C874A3.E64B3980--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LKt7Ei092452 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 13:55:07 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LKt7Z5092451; Thu, 21 Feb 2008 13:55:07 -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.13.5/8.13.5) with SMTP id m1LKt69Y092442 for <[e-mail]>; Thu, 21 Feb 2008 13:55:06 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 10942 invoked from network); 21 Feb 2008 20:55:05 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.10.201 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 21 Feb 2008 20:55:04 -0000
X-YMail-OSG: oMBNYUkVM1l9kVp9N.qbX6oEyxRorzKaJWsQB1iLu3bFPCoaQwY3pJke1Oz3Q.gLX_7_KbpBckFHdznsnPY9QiU6yqVdn.raZFcodZToelnVZ8FwZPIXfunXvO8lCNkXYYUv37YjRaAEgWo-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'Timothy J Miller'" <[e-mail]>, "'Santosh Chokhani'" <[e-mail]>
Cc: "'Stefan Santesson'" <[e-mail]>, "'Russ Housley'" <[e-mail]>, <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 15:48:02 -0500
Organization: IECA, Inc.
Message-ID: <00ba01c874cb$0d38aba0$0301a8c0@Wylie>
MIME-Version: 1.0
Content-Type: application/x-pkcs7-mime; smime-type=signed-data; name="smime.p7m"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7m"
X-Mailer: Microsoft Office Outlook 11
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
in-reply-to: <[e-mail]>
Thread-Index: Ach0y0G6Ip0NQ2NkTbCtxpcu4O4M/AAAH+RQ
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAaCAJIAEgglpQ29u
dGVudC1UeXBlOiB0ZXh0L3BsYWluOw0KCWNoYXJzZXQ9InVzLWFzY2lpIg0KQ29udGVudC1UcmFu
c2Zlci1FbmNvZGluZzogN2JpdA0KDQpUaGUgYWNjZXNzIGNvbnRyb2wgc3lzdGVtIGlzIHN0aWxs
IGluIGNvbnRyb2wgb2YgYWNjZXNzLiAgVGhlIG91dHB1dCBvZiB0aGUNCnBhdGggcHJvY2Vzc2lu
ZyBpcyB0aGUgc3ViamVjdCdzIGNsZWFyYW5jZXMgbm90IGFuIGFjY2VzcyBjb250cm9sIGRlY2lz
aW9uLg0KVGhlIG91dHB1dCBvZiB0aGUgcGF0aCBwcm9jZXNzaW5nIGNhbiBiZSBwYXNzZWQgdG8g
dGhlIGFjY2VzcyBjb250cm9sIHN5c3RlbQ0KdG8gbWFrZSBpdCdzIGRlY2lzaW9uLg0KDQpzcHQN
Cg0KPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogb3duZXItaWV0Zi1wa2l4QG1h
aWwuaW1jLm9yZyANCj5bbWFpbHRvOm93bmVyLWlldGYtcGtpeEBtYWlsLmltYy5vcmddIE9uIEJl
aGFsZiBPZiBUaW1vdGh5IEogTWlsbGVyDQo+U2VudDogVGh1cnNkYXksIEZlYnJ1YXJ5IDIxLCAy
MDA4IDM6MTIgUE0NCj5UbzogU2FudG9zaCBDaG9raGFuaQ0KPkNjOiBTdGVmYW4gU2FudGVzc29u
OyBSdXNzIEhvdXNsZXk7IGlldGYtcGtpeEBpbWMub3JnDQo+U3ViamVjdDogUmU6IENsZWFyYW5j
ZSAmIENBIENsZWFyYW5jZSBDb25zdHJhaW50cyBDZXJ0IEV4dCBJRA0KPg0KPk9uIEZlYiAyMSwg
MjAwOCwgYXQgMTE6MTYgQU0sIFNhbnRvc2ggQ2hva2hhbmkgd3JvdGU6DQo+DQo+PiBMZXQgdXMg
bG9vayBhdCB0aGUgaXNzdWUgb2YgY2xlYXJhbmNlIGluIGEgY2VydGlmaWNhdGUgZmlyc3QuICBU
aGUgDQo+PiByZWFzb24gdG8gaW5jbHVkZSB0aGUgY2xlYXJhbmNlIGluIGEgY2VydGlmaWNhdGUg
aXMgdGhhdCBpbiBtYW55IA0KPj4gZW52aXJvbm1lbnRzIGNsZWFyYW5jZSBpcyByZWxhdGl2ZWx5
IHN0YXRpYy4NCj4NCj5Pbmx5IGF0IGl0cyBsb3dlc3QgYW5kIGdyb3NzZXN0IGxldmVscy4gIEF0
IGhpZ2hlciBsZXZlbHMsIA0KPmZyZXggYWJvdmUgVVMgVFMsIHNwZWNpYWwgcHJvZ3JhbSBhY2Nl
c3NlcyBjYW4gYmUgdmVyeSANCj5keW5hbWljLS1wYXJ0aWN1bGFybHkgb3ZlciB0aGUgbXVsdGkt
eWVhciBsaWZldGltZSBvZiBhIHVzZXIgDQo+Y2VydGlmaWNhdGUuDQo+DQo+TXkgcGFydGljdWxh
ciBvYmplY3Rpb24gaXMgdGhhdCBieSBpbXBsaWNhdGlvbiB5b3UgYXJlIHJlbHlpbmcgb24gdGhl
DQo+KnJldm9jYXRpb24qIGluZnJhc3RydWN0dXJlIHRvIGNvbnRyb2wgYWNjZXNzIHRvIG1hdGVy
aWFscyANCj5iYXNlZCBvbiBjbGVhcmFuY2UuICBUaGlzIGlzIHVud2lzZS4gIFJldm9jYXRpb24g
aXMgbmVpdGhlciANCj5ndWFyYW50ZWVkIG5vciB0aW1lbHkgaW4gcmVhbC13b3JsZCBQS0lzLS1w
YXJ0aWN1bGFybHkgbGFyZ2UgDQo+b25lcy4gIEFjY2VzcyBpcyBiZXR0ZXIgY29udHJvbGxlZCBi
eSwgd2VsbCwgYWNjZXNzIGNvbnRyb2wgc3lzdGVtcy4NCj4NCj4+IEFsc28sIGFzc2VydGluZyBj
bGVhcmFuY2UNCj4+IGluIGNlcnRpZmljYXRlcyBpcyBhcHByb3ByaWF0ZSBzaW5jZSBzZWN1cml0
eSBvZmZpY2Ugd2hvIGtub3dzIG9yIA0KPj4gaG9sZHMgcGVyc29ubmVsIGNsZWFyYW5jZXMgYWxz
byBpcyBpbnZvbHZlZCBpbiBpc3N1aW5nIGNlcnRpZmljYXRlcy4NCj4NCj5UaGlzIGlzIG5vdCB0
cnVlIGV2ZXJ5d2hlcmUuICBEb0QgY2VydGlmaWNhdGVzIGFyZSBtYW5hZ2VkIGJ5IA0KPnBlcnNv
bm5lbCBvZmZpY2VzLCBub3Qgc2VjdXJpdHkuDQo+DQo+PiBGaW5hbGx5LA0KPj4gcHV0dGluZyB0
aGVtIGluIGNlcnRpZmljYXRlcyBhbmQgdmV0dGluZyB0aGVtIHByb3ZpZGVzIGEgY29zdC0gDQo+
PiBlZmZlY3RpdmUgYmluZGluZy4NCj4NCj5TbyBkbyBhdHRyaWJ1dGUgY2VydHMuICBIb3dldmVy
LCB5b3UncmUgYWxzbyBvdmVybG9va2luZyB0aGUgDQo+aGlkZGVuIGNvc3RzIGNhdXNlZCBieSBh
ZGRpdGlvbmFsbHkgYnVyZGVuaW5nIHRoZSByZXZvY2F0aW9uIA0KPmluZnJhc3RydWN0dXJlLS0g
YmVjYXVzZSBpZiB5b3UncmUgdXNpbmcgYSBjbGVhcmFuY2UgZXh0ZW5zaW9uIA0KPkkgKmd1YXJh
bnRlZSogeW91J2xsIGVuZCB1cCBkb2luZyBtb3JlIHJldm9jYXRpb25zLg0KPg0KPj4gU28sIEkg
aGF2ZSB0aGUgZm9sbG93aW5nIHF1ZXN0aW9uIGZvciB5b3U6IERvIHlvdSBoYXZlIGEgYmV0dGVy
IA0KPj4gc3VnZ2VzdGlvbiB0byBtZWV0IHRoZSBuZWVkcyB0byBjb21tdW5pdGllcyB0aGF0IG5l
ZWQgdG8gcHJvY2VzcyANCj4+IGNsZWFyYW5jZXMgaW4gc2VjdXJlIG1hbm5lcj8NCj4NCj5ZZXMs
IEkgZG8uICBJbnZlc3QgaW4gYW4gaWRlbnRpdHkgbWFuYWdlbWVudCBzeXN0ZW0gYW5kIGFuDQo+
KmF1dGhvcml6YXRpb24qIGZyYW1ld29yay4gIFlvdSdsbCBiZSBiZXR0ZXIgb2ZmLg0KPg0KPi0t
IFRpbQ0KPg0KPg0KAAAAAAAAoIIL1zCCAj0wggGmAhEAzbp/VvDf5LxU/iKss3KqVTANBgkqhkiG
9w0BAQIFADBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsT
LkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNOTYwMTI5
MDAwMDAwWhcNMjgwODAxMjM1OTU5WjBfMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24s
IEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRo
b3JpdHkwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBAOUZv22jVmEtmUhx9mfeuY3rt56GgAqR
Dvo4Ja9GiILlc6igmyRdDR/MZW4MsNBWhBiHmgabEKFz37RYOWtuwfYV1aioP6oSBo0xrH+wNNeP
NGeICc0UEeJORVZpH3gCgNrcR5EpuzbJY1zF4Ncth3uhtzKwezC6Ki8xqu6jZ9rbAgMBAAEwDQYJ
KoZIhvcNAQECBQADgYEATD+4i8Zo3+5DMw5d6abLB4RNejP/khv0Nq3YlSI2aBFsfELM85wuxAc/
FLAPT/+Qknb54rxK6Y/NoIAK98Up8YIiXbix3YEjo3slFUYweRb46gVLlH8dwhzI47f0EEA8E8Nf
H1PoSOSGtHuhNbB7Jbq4046rPzidADQAmPPRcZQwggTCMIIDqqADAgECAhAjO8kDjOQmZRciTUyk
xbCFMA0GCSqGSIb3DQEBBQUAMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIElu
Yy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVz
ZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25h
IE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJz
Y3JpYmVyIENBIC0gRzIwHhcNMDcwOTI0MDAwMDAwWhcNMDgwOTIzMjM1OTU5WjCCAQ8xFzAVBgNV
BAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMUYwRAYD
VQQLEz13d3cudmVyaXNpZ24uY29tL3JlcG9zaXRvcnkvUlBBIEluY29ycC4gYnkgUmVmLixMSUFC
LkxURChjKTk4MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNDAyBgNVBAsTK0RpZ2l0
YWwgSUQgQ2xhc3MgMSAtIE1pY3Jvc29mdCBGdWxsIFNlcnZpY2UxFDASBgNVBAMUC1NlYW4gVHVy
bmVyMR8wHQYJKoZIhvcNAQkBFhB0dXJuZXJzQGllY2EuY29tMIGfMA0GCSqGSIb3DQEBAQUAA4GN
ADCBiQKBgQDgnF/ti2EqlfkxsvIPaI6GYQdImnjsR+BAN1Zt9sJDQriXFd791aoI6GnTR9GihXOJ
hw9pJxpU9np02EZonlne6DBvSJGANPmHua9jdVdIwUxLJvm6CqNIlyozB9GYKcULhYRZEVo1cHy0
XZkl6SIyCoIeeIUcDkxaJYmfPLvAXwIDAQABo4HMMIHJMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5
BgtghkgBhvhFAQcXAzAqMCgGCCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBh
MAsGA1UdDwQEAwIFoDAdBgNVHSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwSgYDVR0fBEMwQTA/
oD2gO4Y5aHR0cDovL0luZEMxRGlnaXRhbElELWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFs
SUQuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAAHNR7NLrv/0EvrMH+OfIrZ7iDElW7V9nAOIwRQ0el
FN7CgN3N5mzpF5sGwLan2s4Izeq4XbrhCo9O8yX5SvmgrMe4afuHrt1bpxmmWWjNq6y91UwbSw7B
8SaeCdSGDg6BhksmkErUiC+IUVvMxCNNgoU7Ofc7Bzge1et/G1YvyYZDkuQDZ9gF7lx4vKah3irV
fYMoe/k9Rb+jYDTDcpvo8JtBVVe5zS0TFu/PSSg1QT+MYx32TJ4jmod+67DMeHQgPk7ECIjlEln9
kyfSgczIiBoeEhnw/JcTBs7ioBtwRtrD7mXpaFQdnuBydlZfuaSAREJdRZ+TyTFSmsUtL7oeMIIE
zDCCBDWgAwIBAgIQHK6da5r05i8iiqPadGFsHjANBgkqhkiG9w0BAQUFADBfMQswCQYDVQQGEwJV
UzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xNzA1BgNVBAsTLkNsYXNzIDEgUHVibGljIFByaW1h
cnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkwHhcNMDUxMDI4MDAwMDAwWhcNMTUxMDI3MjM1OTU5
WjCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJp
U2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cu
dmVyaXNpZ24uY29tL3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcw
NQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyMIIB
IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAyd+s5+r4+AMUxACS1cF+NsI873xyFcvAq4w9
HJXObx4QLD8A7Zcm5rbH5q1DHT+kh0dHTD5U+Gz4x/yxnr0wcLyXsQMF6pXxrUDFRHpLBaLyYPzX
OmVi7/8Qe6JWu8VOcC3Woh887bBC6F6NVyGsppnZEenSGgfAdEdCC/zFNOr95rok0R0IFTei13PP
AUEvY7I6P76lGm70yUpbPZWmFbs1Ahn51O+8jw5xdlm7S7Y+1vxaFvTWDonySf5sDO0V6dmIdZx5
zmAn3bmtdc4vc5V6QDqFdUmwuN9ovKvNE4KFEVCj4DwLrsAKU83XMG+FMkYb5EkQwmzirx95/9u0
tQIDAQABo4IBhDCCAYAwEgYDVR0TAQH/BAgwBgEB/wIBADBEBgNVHSAEPTA7MDkGC2CGSAGG+EUB
BxcBMCowKAYIKwYBBQUHAgEWHGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEwCwYDVR0PBAQD
AgEGMBEGCWCGSAGG+EIBAQQEAwIBBjAuBgNVHREEJzAlpCMwITEfMB0GA1UEAxMWUHJpdmF0ZUxh
YmVsMy0yMDQ4LTE1NTAdBgNVHQ4EFgQUEX1eGX08BN9qbNaiiho/Mdg7lFIwMQYDVR0fBCowKDAm
oCSgIoYgaHR0cDovL2NybC52ZXJpc2lnbi5jb20vcGNhMS5jcmwwgYEGA1UdIwR6MHihY6RhMF8x
CzAJBgNVBAYTAlVTMRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjE3MDUGA1UECxMuQ2xhc3MgMSBQ
dWJsaWMgUHJpbWFyeSBDZXJ0aWZpY2F0aW9uIEF1dGhvcml0eYIRAM26f1bw3+S8VP4irLNyqlUw
DQYJKoZIhvcNAQEFBQADgYEAsS/ZluGSou6BYOXIKiD74Wcs1gCYU6MCG+mQS/gYRJ8PRvf6oP7T
HRij0r8c7NYZn0pNQ/jKu74TgEkF3SFzM1fCQlq++gCTsuYEMZFOXTzwcwU3Y+u/g1mY/Wbe6YYy
mpIpPDquVNqmElGxj8jK00d45tulHocG49EUwMIh9roxggRzMIIEbwIBATCB8jCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAjO8kDjOQmZRciTUyk
xbCFMAkGBSsOAwIaBQCgggLWMBgGCSqGSIb3DQEJAzELBgkqhkiG9w0BBwEwHAYJKoZIhvcNAQkF
MQ8XDTA4MDIyMTIwNDgwMVowIwYJKoZIhvcNAQkEMRYEFGn78GoQlT9l8bPpndGaf/r/eZNwMGcG
CSqGSIb3DQEJDzFaMFgwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3DQMCAgFA
MAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMAcGBSsOAwIaMAoGCCqGSIb3DQIFMIIBAwYJKwYBBAGC
NxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV
BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRw
czovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChjKTA1MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxp
ZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENsYXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENB
IC0gRzICECM7yQOM5CZlFyJNTKTFsIUwggEFBgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UE
BhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBO
ZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29t
L3JwYSAoYykwNTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJp
U2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEcyAhAjO8kDjOQmZRciTUyk
xbCFMA0GCSqGSIb3DQEBAQUABIGAA1cPI3zIb24YpfxgxvMpVOdAf6uCWngJw80Pxi1rXvQRedu4
+C/5AlwKq1awy8cYVaNelwxBDLwtM8eya1QwrVCdmWhMf5OzoS3lvQn88rfgr9WZS4luPhr8Dv3P
2XBUAfG2u7kEzT/B4Jiup5Ns0ycP64Bczy/wQw+7xFssthMAAAAAAAA=



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LKmf34092003 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 13:48:41 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LKmfNU092002; Thu, 21 Feb 2008 13:48:41 -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.13.5/8.13.5) with SMTP id m1LKme1j091994 for <[e-mail]>; Thu, 21 Feb 2008 13:48:41 -0700 (MST) (envelope-from [e-mail])
Message-Id: <[e-mail]>
Received: (qmail 22039 invoked by uid 0); 21 Feb 2008 20:48:28 -0000
Received: from unknown (HELO THINKPADR52.vigilsec.com) (72.83.129.167) by woodstock.binhost.com with SMTP; 21 Feb 2008 20:48:28 -0000
X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9
Date: Thu, 21 Feb 2008 15:48:30 -0500
To: Timothy J Miller <[e-mail]>
From: Russ Housley <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: [e-mail]
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Tim:

>>Let us look at the issue of clearance in a certificate first.  The
>>reason to include the clearance in a certificate is that in many
>>environments clearance is relatively static.
>
>Only at its lowest and grossest levels.  At higher levels, frex above
>US TS, special program accesses can be very dynamic--particularly
>over the multi-year lifetime of a user certificate.
>
>My particular objection is that by implication you are relying on the
>*revocation* infrastructure to control access to materials based on
>clearance.  This is unwise.  Revocation is neither guaranteed nor
>timely in real-world PKIs--particularly large ones.  Access is better
>controlled by, well, access control systems.

Yes, and no.

If people place short-lived authorization information in the public 
key certificate (PKC), then they will have many management 
headaches.  This is only appropriate for very stable authorization 
information. This is related to RFC 3281, which says:

    Authorization information may be placed in a PKC extension or placed
    in a separate attribute certificate (AC).  The placement of
    authorization information in PKCs is usually undesirable for two
    reasons.  First, authorization information often does not have the
    same lifetime as the binding of the identity and the public key.
    When authorization information is placed in a PKC extension, the
    general result is the shortening of the PKC useful lifetime.  Second,
    the PKC issuer is not usually authoritative for the authorization
    information.  This results in additional steps for the PKC issuer to
    obtain authorization information from the authoritative source.

I believe that this is all still correct.  Yet, there are people that 
want to put clearance information into public key certificates.  It 
is important to me that the syntax for representing the clearance in 
a certificate and an attribute certificate are exactly the same.  RFC 
3281 already specifies it for an attribute certificate.  There are 
folks who are going to put clearance information in a 
certificate.  I'd like them all to do it the same way, so that when 
policy permits, they can interoperate.

>>Also, asserting clearance
>>in certificates is appropriate since security office who knows or
>>holds personnel clearances also is involved in issuing certificates.
>
>This is not true everywhere.  DoD certificates are managed by
>personnel offices, not security.

This is covered by the quoted text from RFC 3281.  Yet, some people 
really want to impose the extra step on CAs in support of real 
applications.  Again, I'd like them all to do it the same way, so 
that when policy permits, they can interoperate.

>>Finally,
>>putting them in certificates and vetting them provides a cost- effective
>>binding.
>
>So do attribute certs.  However, you're also overlooking the hidden
>costs caused by additionally burdening the revocation 
>infrastructure-- because if you're using a clearance extension I 
>*guarantee* you'll
>end up doing more revocations.

No doubt.  This argument has not deterred the folks that want to do it.

>>So, I have the following question for you: Do you have a better
>>suggestion to meet the needs to communities that need to process
>>clearances in secure manner?
>
>Yes, I do.  Invest in an identity management system and an
>*authorization* framework.  You'll be better off.

As an author of RFC 3281, I've made these same arguments to no 
avail.  So, the reason I want to see PKIX take this on it to allow a 
straight forward migration to attribute certificates (because the 
same syntax is used).   If each organization that wants to do this 
does it their own way, we will be much worse off.

Russ



Received: from hfi34.internetdsl.tpnet.pl (hfi34.internetdsl.tpnet.pl [79.187.138.34]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LKQDLa090139 for <[e-mail]>; Thu, 21 Feb 2008 13:26:18 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000701c874c8$050760f0$228abb4f@sully>
From: "Asher hoekstra" <[e-mail]>
To: [e-mail]
Subject: Tired of the stares you get for your tiny pecker? Click here now.
Date: Thu, 21 Feb 2008 21:26:20 +0100
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0003_01C874D0.66CBC8F0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198

----------=_NextPart_000_0003_01C874D0.66CBC8F0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Amazing growth in just a few short weeks can be yours.
----------=_NextPart_000_0003_01C874D0.66CBC8F0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.rollplastico.com/">Amazing growth in just a few =
short weeks=20
can be yours.</A></BODY></HTML>
----------=_NextPart_000_0003_01C874D0.66CBC8F0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LKFAEE088627 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 13:15:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LKFAFZ088625; Thu, 21 Feb 2008 13:15:10 -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.13.5/8.13.5) with ESMTP id m1LKFAJf088613 for <[e-mail]>; Thu, 21 Feb 2008 13:15:10 -0700 (MST) (envelope-from [e-mail])
Received: by core3.amsl.com (Postfix, from userid 0) id 0A7E728CB3D; Thu, 21 Feb 2008 12:15:01 -0800 (PST)
Content-Type: Multipart/Mixed; Boundary="NextPart"
Mime-Version: 1.0
To: [e-mail]
Cc: [e-mail]
From: [e-mail]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-03.txt 
Message-Id: <[e-mail]>
Date: Thu, 21 Feb 2008 12:15:01 -0800 (PST)
Sender: [e-mail]
Precedence: 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-03.txt
	Pages		: 19
	Date		: 2008-2-21
	
This document specifies the syntax and semantics for the Subject 
   Public Key Information field in certificates that support Elliptic 
   Curve Cryptography.  This document updates RFC 3279.

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

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

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

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

--NextPart--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LKDO8e088317 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 13:13:24 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LKDOxH088316; Thu, 21 Feb 2008 13:13:24 -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.13.5/8.13.5) with ESMTP id m1LKDM3i088306 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 13:13:23 -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 m1LKDMMS007179 for <[e-mail]>; Thu, 21 Feb 2008 15:13:22 -0500
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1LKDMjL007175; Thu, 21 Feb 2008 15:13:22 -0500
Received: from [208.54.136.177] ([172.31.6.26]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 15:13:20 -0500
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-2--168221769; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
From: Timothy J Miller <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 14:12:40 -0600
To: Stefan Santesson <[e-mail]>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 21 Feb 2008 20:13:21.0431 (UTC) FILETIME=[3490CA70:01C874C6]
Sender: [e-mail]
Precedence: 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--168221769
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed


On Feb 21, 2008, at 10:07 AM, Stefan Santesson wrote:

> Including authorization and clearance information in certificates  
> is both tricky and dangerous. In my opinion certificates is the  
> least suitable place for such information.

Amen brother.  Preach it!

-- Tim


--Apple-Mail-2--168221769
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjIxMjAxMjQx
WjAjBgkqhkiG9w0BCQQxFgQUCLlj9lCLU9DBPjLvxaFwa36cr4wwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYAuH5IY7mcHS0i9Pvgs68DR8/SnPes+/WY0MSL4Y0rirazd/F3GxlI9Xmw6yFk+po8i2uIW
LEFa62AXmuTq6ZCMl4Pz6myJLW2LkktwpDxcQcdovlGBl1VBpZ0qGSQqDjgF7UDU5Nmd/rmMQ+Te
Nr3Vg9zw5SAJO6T1YNwTrQgszQAAAAAAAA==

--Apple-Mail-2--168221769--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LKCjjT088210 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 13:12:45 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LKCim0088208; Thu, 21 Feb 2008 13:12:45 -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.13.5/8.13.5) with ESMTP id m1LKCgsZ088196 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 13:12:43 -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 m1LKCftf005733 for <[e-mail]>; Thu, 21 Feb 2008 15:12:42 -0500
Received: from imcfe2.MITRE.ORG (imcfe2.mitre.org [129.83.29.4]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id m1LKCf2J005728; Thu, 21 Feb 2008 15:12:41 -0500
Received: from [208.54.136.177] ([172.31.6.26]) by imcfe2.MITRE.ORG with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 15:12:39 -0500
In-Reply-To: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
Mime-Version: 1.0 (Apple Message framework v753)
Content-Type: multipart/signed; micalg=sha1; boundary=Apple-Mail-1--168263324; protocol="application/pkcs7-signature"
Message-Id: <[e-mail]>
Cc: "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
From: Timothy J Miller <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 14:11:49 -0600
To: "Santosh Chokhani" <[e-mail]>
X-Mailer: Apple Mail (2.753)
X-OriginalArrivalTime: 21 Feb 2008 20:12:40.0823 (UTC) FILETIME=[1C5C8070:01C874C6]
Sender: [e-mail]
Precedence: 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--168263324
Content-Transfer-Encoding: 7bit
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed

On Feb 21, 2008, at 11:16 AM, Santosh Chokhani wrote:

> Let us look at the issue of clearance in a certificate first.  The
> reason to include the clearance in a certificate is that in many
> environments clearance is relatively static.

Only at its lowest and grossest levels.  At higher levels, frex above  
US TS, special program accesses can be very dynamic--particularly  
over the multi-year lifetime of a user certificate.

My particular objection is that by implication you are relying on the  
*revocation* infrastructure to control access to materials based on  
clearance.  This is unwise.  Revocation is neither guaranteed nor  
timely in real-world PKIs--particularly large ones.  Access is better  
controlled by, well, access control systems.

> Also, asserting clearance
> in certificates is appropriate since security office who knows or  
> holds
> personnel clearances also is involved in issuing certificates.

This is not true everywhere.  DoD certificates are managed by  
personnel offices, not security.

> Finally,
> putting them in certificates and vetting them provides a cost- 
> effective
> binding.

So do attribute certs.  However, you're also overlooking the hidden  
costs caused by additionally burdening the revocation infrastructure-- 
because if you're using a clearance extension I *guarantee* you'll  
end up doing more revocations.

> So, I have the following question for you: Do you have a better
> suggestion to meet the needs to communities that need to process
> clearances in secure manner?

Yes, I do.  Invest in an identity management system and an  
*authorization* framework.  You'll be better off.

-- Tim


--Apple-Mail-1--168263324
Content-Transfer-Encoding: base64
Content-Type: application/pkcs7-signature;
	name=smime.p7s
Content-Disposition: attachment;
	filename=smime.p7s

MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIHUzCCA2cw
ggJPoAMCAQICAgaaMA0GCSqGSIb3DQEBBQUAMF0xEjAQBgNVBAoTCW1pdHJlLm9yZzEeMBwGA1UE
CxMVQ2VydGlmaWNhdGUgQXV0aG9yaXR5MScwJQYDVQQDEx5NSVRSRSBDb3Jwb3JhdGlvbiBQcmlt
YXJ5IENBLTEwHhcNMDcwMjI4MTM1MTI0WhcNMDgwODIxMTM1MTI0WjBaMRIwEAYDVQQKEwltaXRy
ZS5vcmcxDzANBgNVBAsTBnBlb3BsZTEXMBUGCgmSJomT8ixkAQETB3RtaWxsZXIxGjAYBgNVBAMT
EU1pbGxlciBUaW1vdGh5IEouMIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDdpUHmSTmvwH16
KCBA3uXosw5bClu9nThq5kU/869taPaoWotpX1jnucczEnSrAwgBO9Ns7PIOpCtarIIOL2pRyX7e
xHs6IqmLY+3o3ew1lNZ5gJWhAiy+DBPGrhgDXkHqFAhLho0TA+09uroEmhCZARC3XZHk3pW8/jUS
+lHzLQIDAQABo4G3MIG0MA4GA1UdDwEB/wQEAwIF4DAdBgNVHQ4EFgQUXClSdJbPKPEdSSFG1e6J
IelCzrswHwYDVR0jBBgwFoAUh7QPSI1iM0LBLVEaSB7CnrsKsa0wRAYDVR0fBD0wOzA5oDegNYYz
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL2NhMV9taXRyZV9vcmcuY3JsMBwGA1Ud
EQQVMBOBEXRtaWxsZXJAbWl0cmUub3JnMA0GCSqGSIb3DQEBBQUAA4IBAQC6kURYV/MoIAl9Un6n
KXJ63Fi7y50uR7+f729M3QU3Em+/Is0XDAQ0oFERQu9kZQx6IQt0UFyTwZfDYmjYYOJAEB/691KS
DYBOeu4mzhwASbV7qSrTiDEbFqXupCKKXk5mRD6ECC0os8WF0kEkrUJPdGblBYfjta36hSqC8fOp
gvCLE8JNJIbPr3EmbSsApo0aeXtZZk/q8VNOvM/L25Pxb4TGF9puMUZ8nBolr1obM7aaGXmyGm5A
voGeZBbsnxG9LX+pRM4AP0S5Ttl1CtKReLX7PU0OVcing9RzC02dRxL8OUz53PYqNcJ0xmiwnPec
zCCEYjocKb0dx/U9yMJnMIID5DCCAsygAwIBAgIBBTANBgkqhkiG9w0BAQUFADBaMRIwEAYDVQQK
EwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEkMCIGA1UEAxMbTUlU
UkUgQ29ycG9yYXRpb24gUm9vdCBDQS0xMB4XDTA2MDYwMzE3MTMyMloXDTEyMDYwMzE3MTMyMlow
XTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkxJzAl
BgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMTCCASIwDQYJKoZIhvcNAQEBBQAD
ggEPADCCAQoCggEBAMjwe1ZdEIKoELdLvENnbkbO3mVD54ZX5SjxTzFxhvoqhqSJmLOp32xT7J9K
vBapJRbJv1BFdiSUN3O0q8H66nvQqwm1RYe+tTsWSO351FolGrDT9iDRtfWgH60PCKCbABLRsx3i
GnEvjOQjeAtMn1AugqQWU3PWZXYy1Grbya+NOytYvu1p60bDFSoSAn4Jojv14lUfWHl8s3kahay8
umLSQibiXdEEX8CrSkaXpOaFOuyM6+wpRw7TybO1Dk4zGAUtn0887QvsMDk6evgN2WxMprkHAGUc
JhpI1QXtkfDIl9ukdNiIoM/vdN2QC/+m6b8dA55K5UdlBa9SgRnwapkCAwEAAaOBsTCBrjASBgNV
HRMBAf8ECDAGAQH/AgECMA4GA1UdDwEB/wQEAwIBhjAdBgNVHQ4EFgQUh7QPSI1iM0LBLVEaSB7C
nrsKsa0wHwYDVR0jBBgwFoAUx3BRANhN/uQB1GiWxT2fmpf+dC8wSAYDVR0fBEEwPzA9oDugOYY3
aHR0cDovL3d3dy5taXRyZS5vcmcvdGVjaC9taWkvcGtpL3Jvb3RjYTFfbWl0cmVfb3JnLmNybDAN
BgkqhkiG9w0BAQUFAAOCAQEATW5u664p7N0iAj27Xl/akjdfkSQpaosf6cNyAHu7utCytFfY1WfR
NmvnNDGYkqI3XMFOa18SNjiNsMCH+sFQaO+oyDnPiIkEZQvlfGGrRpqIm6j//Fgz85bnf1kAM5I6
1Np7ofCnciRvp9ZB/+u+9i262tgiJPJrvBcqXmgeT9riCc3RPjxqPNmYslOvNLpIifchelJhF7nI
ge+7RkAUcTJenj8yKwK0J3+PEpgYRQ+V2C62rnjohuxPgMw/fYoNTOlh3MVl7adwyK1ahPw2a9eO
jSWglqoPTaBNeHJqRJZZ6Vi7S55+VAWCfkAqM5m3tUiVzjsp2dFcTJxnYezaoDGCAlQwggJQAgEB
MGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowCQYFKw4DAhoFAKCC
AUcwGAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMDgwMjIxMjAxMTQ5
WjAjBgkqhkiG9w0BCQQxFgQU4SG+AWJTdRDV5+AYOiX1SFzvDmQwcgYJKwYBBAGCNxAEMWUwYzBd
MRIwEAYDVQQKEwltaXRyZS5vcmcxHjAcBgNVBAsTFUNlcnRpZmljYXRlIEF1dGhvcml0eTEnMCUG
A1UEAxMeTUlUUkUgQ29ycG9yYXRpb24gUHJpbWFyeSBDQS0xAgIGmjB0BgsqhkiG9w0BCRACCzFl
oGMwXTESMBAGA1UEChMJbWl0cmUub3JnMR4wHAYDVQQLExVDZXJ0aWZpY2F0ZSBBdXRob3JpdHkx
JzAlBgNVBAMTHk1JVFJFIENvcnBvcmF0aW9uIFByaW1hcnkgQ0EtMQICBpowDQYJKoZIhvcNAQEB
BQAEgYBUtqRkbseEgaKdt3Z6PheZGA7Z7uyhn++V3/uL4NNoKzj5QaS31KT2P9Hw25DJ/gBU5Z0b
ozYI62ky8g0SnAn1rsfxGqcse6AMylyyL1aq6yKJjfZ/OD0X9WGwpuzbW8hZ6BtYeaL9gCHxQC8C
Xuv+rN92jMzWnkPSBjDJmb6RnQAAAAAAAA==

--Apple-Mail-1--168263324--



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LK6Hku087228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 13:06:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LK6Hnv087227; Thu, 21 Feb 2008 13:06:17 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LK6DNN087212 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 13:06:16 -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 m1LK68MU029009 for <[e-mail]>; Thu, 21 Feb 2008 15:06:08 -0500
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 m1LK5uEE001101 for <[e-mail]>; Thu, 21 Feb 2008 15:05:57 -0500
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 15:05:51 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (X11/20080213)
MIME-Version: 1.0
To: pkix <[e-mail]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[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>

Stefan Santesson wrote:
> We can simply choose to ignore it or acknowledge it, but we can't change it.
> However we do not have to standardize it. But we may want to document it. This is what Informational RFCs are there for.
>
> I'm supportive of an effort to document this in an IETF document.
>   

Stefan,

If the scope of the document is limited to describing how to include a 
wildcard DNS name in the subject field (i.e., within a common name 
attribute), then I agree that it can be an informational RFC.  However, 
if the document is going to describe inclusion of wildcard DNS names in 
the dNSName field of the subjectAltName extension, then I think that it 
also needs to explain how name constraints on DNS names should be 
processed when such a name is encountered, and that seems like something 
that belongs in an update to 3280bis, not an informational RFC.  Also, 
any mention of including wildcard DNS names in the dNSName field of the 
subjectAltName extension would contradict 3280bis, which would also seem 
to argue in favor of writing it as an update to 3280bis.

Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LIYSsF078500 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 11:34:28 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LIYSaJ078499; Thu, 21 Feb 2008 11:34:28 -0700 (MST) (envelope-from [e-mail])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [e-mail] using -f
Received: from smtp.cs.tcd.ie (relay.cs.tcd.ie [134.226.32.56]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LIYQET078489 for <[e-mail]>; Thu, 21 Feb 2008 11:34:27 -0700 (MST) (envelope-from [e-mail])
Received: from localhost (localhost [127.0.0.1]) by relay.cs.tcd.ie (Postfix) with ESMTP id BD67DF3408; Thu, 21 Feb 2008 18:34:25 +0000 (GMT)
X-Virus-Scanned: amavisd-new at cs.tcd.ie
Received: from smtp.cs.tcd.ie ([127.0.0.1]) by localhost (smtp.cs.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4jiYU4S2WlSq; Thu, 21 Feb 2008 18:34:25 +0000 (GMT)
Received: from [134.226.36.180] (sfarrell.dsg.cs.tcd.ie [134.226.36.180]) by smtp.cs.tcd.ie (Postfix) with ESMTP id 28EDB53E8A; Thu, 21 Feb 2008 18:34:24 +0000 (GMT)
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 18:34:26 +0000
From: Stephen Farrell <[e-mail]>
User-Agent: Thunderbird 2.0.0.9 (Windows/20071031)
MIME-Version: 1.0
To: "Kemp, David P." <[e-mail]>
CC: [e-mail]
Subject: Re: Wildcard DNS. Re: rfc 3280bis
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[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
Sender: [e-mail]
Precedence: 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:
> There are a bunch of bad things permitted by the HTML 4.01 Transitional
> DTD (loose) that are not permitted by the HTML 4.01 DTD (strict).
> Making the web work involved content authors taking into consideration
> the behavior of the installed browser base, while providing a path
> toward standards compliance by enabling authors and users to recognize
> non-standard content.

I'd support documenting the de-facto situation.

> If the proposed informational RFC is published, it should include a
> recommendation that certificate-consuming applications be configurable
> to warn when wildcard or otherwise non-standard certificates are
> encountered.  Probably some CAs will continue to produce broken certs
> and many consumers will choose to turn off the warnings, but IETF
> documents (standards and informational) should promote transition to
> correct behavior, not ossify the status quo.
> 
> If Firefox and IE7 had a check box to warn on broken certs I would leave
> it checked, and I would provide feedback to the offending websites.

Let's not do that. There're already too many silly (to end users)
PKI warnings that browsers show, adding more is a bad idea, since
they just habituate users to clicking "ok" regardless.

Stephen.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LIQcd2077679 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 11:26:38 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LIQcI0077678; Thu, 21 Feb 2008 11:26:38 -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.13.5/8.13.5) with SMTP id m1LIQbGs077669 for <[e-mail]>; Thu, 21 Feb 2008 11:26:38 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 29571 invoked from network); 21 Feb 2008 18:19:02 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 18:19:02 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 18:19:02 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 13:26:35 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: AchVQOG5UgddOVvDQg+e41vGLubOBAfYRucgAAUXX0A=
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LIQcGs077671
Sender: [e-mail]
Precedence: 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>

Further, the extension of this draft affects path validation. This means
that supporting this extension involves a HUGE commitment from product
development compared to an extension that is only parsed locally in the
relying party's application. An extension that is processed in path
validation requires not only changes to the path validation algorithm.
It will also require API changes to accommodate status and error codes
as well as results.

[CRW] The sort of operation described in the draft could be performed as
post-processing using the output of a vanilla 3280 path processor.
Direct integration into a 3280 engine is not required but could be
implemented where desired.  Maybe the draft should state something along
those lines.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LI2YYY073903 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 11:02:34 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LI2Y64073902; Thu, 21 Feb 2008 11:02:34 -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.13.5/8.13.5) with ESMTP id m1LI2XIv073892 for <[e-mail]>; Thu, 21 Feb 2008 11:02:33 -0700 (MST) (envelope-from [e-mail])
Received: from Cerberus (cerberus.missi.ncsc.mil [144.51.51.8]) by stingray.missi.ncsc.mil with ESMTP id m1LI2WCV010516 for <[e-mail]>; Thu, 21 Feb 2008 13:02:32 -0500 (EST)
X-AuditID: 90333308-000013b400000754-49-47bdbd030be4
Received: from antigone.missi.ncsc.mil ([144.51.60.33]) by Cerberus with Microsoft SMTPSVC(6.0.3790.1830); Thu, 21 Feb 2008 13:03:47 -0500
Received: from EXCH.missi.ncsc.mil ([144.51.60.19]) by antigone.missi.ncsc.mil with Microsoft SMTPSVC(6.0.3790.3959); Thu, 21 Feb 2008 13:03:47 -0500
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Date: Thu, 21 Feb 2008 13:03:42 -0500
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Wildcard DNS. Re: rfc 3280bis
Thread-Index: AchwPYA+Tw5egkrdRRefXBDJQ1qGLAEaGnJAAAJVMSA=
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]> <[e-mail]>
From: "Kemp, David P." <[e-mail]>
To: <[e-mail]>
X-OriginalArrivalTime: 21 Feb 2008 18:03:47.0366 (UTC) FILETIME=[1ADC9C60:01C874B4]
X-Brightmail-Tracker: AAAAAA==
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LI2YIv073897
Sender: [e-mail]
Precedence: 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 a bunch of bad things permitted by the HTML 4.01 Transitional
DTD (loose) that are not permitted by the HTML 4.01 DTD (strict).
Making the web work involved content authors taking into consideration
the behavior of the installed browser base, while providing a path
toward standards compliance by enabling authors and users to recognize
non-standard content.

If the proposed informational RFC is published, it should include a
recommendation that certificate-consuming applications be configurable
to warn when wildcard or otherwise non-standard certificates are
encountered.  Probably some CAs will continue to produce broken certs
and many consumers will choose to turn off the warnings, but IETF
documents (standards and informational) should promote transition to
correct behavior, not ossify the status quo.

If Firefox and IE7 had a check box to warn on broken certs I would leave
it checked, and I would provide feedback to the offending websites.

Dave


-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Thursday, February 21, 2008 11:33 AM
To: Stephen Kent; Peter Gutmann
Cc: [e-mail]; [e-mail]
Subject: RE: Wildcard DNS. Re: rfc 3280bis


I think this gets to the core of the problem:

> Since the real world is full of broken CA behavior, as you have
> personally document through a multi-year collection of non-compliant
> certs, a note explaining various degrees of brokenness would indeed
> be very long.  It also has no place in this document.  Maybe you
> should submit an April 1st RFC on the topic.

However, let's sort the rotten fruit in the basket a bit.

There are tons of bad certificates out there, but most of them belongs
in local PKI deployment where a local application have learned to
understand the obscure output of a local CA. In such case no or little
harm is made to the global community and standard products. The local
implementation will simply have to choose between changing their use of
PKI or manually tweak every new application making use of certs.

We have only one successful deployment of public certificates, being
server SSL/TLS certificates. Those using it, issuing certificates for it
and developing applications and browsers using it, are not evil people
with an evil agenda. They simply want to make it work. To make it work,
they need to take the behavior of others into the calculation which
includes interworking with a huge base of existing certificates and
applications.

Making it work is far more important than being faithful to any
standard. Sad maybe, but it's a fact of life.

This means that no matter how much we may dislike it, the community out
there will still issue server certificates with dns names in the common
name field and they will produce certificates with wildcards in the dns
name.

We can simply choose to ignore it or acknowledge it, but we can't change
it.
However we do not have to standardize it. But we may want to document
it. This is what Informational RFCs are there for.

I'm supportive of an effort to document this in an IETF document.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Stephen Kent
> Sent: den 16 februari 2008 01:52
> To: Peter Gutmann
> Cc: [e-mail]; [e-mail]
> Subject: Re: Wildcard DNS. Re: rfc 3280bis
>
>
> At 2:14 AM +1300 2/16/08, Peter Gutmann wrote:
> >Stephen Kent <[e-mail]> writes:
> >
> >>RFC 3280, which superseded 2459, removed the reference to wildcard
> characters
> >>in SANs, making it clear that they were no longer acceptable.  3280
> was
> >>published in 2002, 5.5 years ago.
> >
> >Now all we need to do is convince every CA on the planet to stop
> issuing
> >wildcard certificates.  Who wants to have a go first?
>
> not EVERY CA issues such certs. since the notification problem is
> thus not nearly so great as you suggest, I'm willing to delegate this
> awesome responsibility to you.
>
> >
> >>I agree that 2818 should be revised, given that the reference it
> makes to the
> >>PKIX cert profile is now 2 revs (.5. years) out of date, and no
> longer valid.
> >
> >Perhaps 2818bis could contain a note for implementors mapping what
the
> RFCs
> >say to what the world really does.
> >
> >(I suspect it'd be quite a long note).
>
> Since the real world is full of broken CA behavior, as you have
> personally document through a multi-year collection of non-compliant
> certs, a note explaining various degrees of brokenness would indeed
> be very long.  It also has no place in this document.  Maybe you
> should submit an April 1st RFC on the topic.
>
> Steve





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LHGhmj068846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 10:16:43 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LHGhDu068845; Thu, 21 Feb 2008 10:16: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.13.5/8.13.5) with SMTP id m1LHGfYe068837 for <[e-mail]>; Thu, 21 Feb 2008 10:16:42 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 28882 invoked from network); 21 Feb 2008 17:09:06 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 17:09:06 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 17:09:06 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 12:16:39 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: AchVQOG5UgddOVvDQg+e41vGLubOBAfYRucgAAJ9rvA=
References: <006001c85495$093074d0$0301a8c0@Wylie> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "Stefan Santesson" <[e-mail]>, "Russ Housley" <[e-mail]>, <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LHGhYe068840
Sender: [e-mail]
Precedence: 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,

Let us look at the issue of clearance in a certificate first.  The
reason to include the clearance in a certificate is that in many
environments clearance is relatively static.  Also, asserting clearance
in certificates is appropriate since security office who knows or holds
personnel clearances also is involved in issuing certificates.  Finally,
putting them in certificates and vetting them provides a cost-effective
binding.

Now, to your objection regarding path validation.  First of all, the
only time the extra goo is required, is when you want to obtain and
enforce the clearance.  If you do not need to process clearance, you do
not have to.  The only time path processing is impacted is if the CA
asserted clearance constraints as critical.

The processing rules while large to spell out, simply say that do not
delegate something you are not authorized to delegate.  3281
specifically punted on this issue (i.e., AC chain).  So, I do not see
the big problem.  Most access control models, e.g., Role Based Access
Control (RBAC) work that way.  You can not delegate a role unless you
explicitly authorized to delegate the role.

One would think that those implementations that provide chain of
authorizations will need to meet the basic property of not asserting
authorization you are not permitted to delegate.

I also do not see every implementation needing this, unless they want to
provide clearance processing capability.

So, I have the following question for you: Do you have a better
suggestion to meet the needs to communities that need to process
clearances in secure manner?

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of Stefan Santesson
Sent: Thursday, February 21, 2008 11:07 AM
To: Russ Housley; [e-mail]
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID


First I want to apologize for a somewhat late response to this issue. I
have been away from work due to my mother's passing but I'm now fully
back and operational.

I'm somewhat surprised to see such overwhelming support for this draft.
Personally I have some big concerns.

Including authorization and clearance information in certificates is
both tricky and dangerous. In my opinion certificates is the least
suitable place for such information.
Clearance is not just tied to a person, but to systems and I may have a
wide range of clearances in different systems. Clearance may change very
rapidly while certificates and more static declarations of the
relationship between a person and a set of keys. So they do not
naturally mix very well.

Further, the extension of this draft affects path validation. This means
that supporting this extension involves a HUGE commitment from product
development compared to an extension that is only parsed locally in the
relying party's application. An extension that is processed in path
validation requires not only changes to the path validation algorithm.
It will also require API changes to accommodate status and error codes
as well as results.

I don't find any motivation for this new standard that makes me believe
that it is worth the effort and I therefore object to this being adopted
as a PKIX work item.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 12 januari 2008 15:18
> To: [e-mail]
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
> While this extension is primarily useful to a Government/Military
> environment, it does have some applicability to commercial
> environments too.  This situation is demonstrated in RFC 3114.  I see
> advantages to all of the potential users if this specification is
> published on the IETF standards-track.
>
> I encourage the PKIX WG to accept this document.
>
> Russ
>
> At 04:00 PM 1/11/2008, Turner, Sean P. wrote:
>
> >Santosh Chokhani and I have produced an ID that defines an extension
> that
> >holds a subject's clearance. The ID also defines an extension called
> >clearance constraints to limit the clearance values a CA should place
> in
> >subordinate certificates. Finally, it defines the certification path
> >processing rules to determine the clearances for the subject of the
> >certificate based on the clearance and clearance constraints asserted
> in the
> >certification path. The ID can be found at:
> >
> >http://www.ietf.org/internet-drafts/draft-turner-
> caclearanceconstraints-00.t
> >xt
> >
> >We're hoping that PKIX would be willing to adopt this as a work item.
> >
> >spt





Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGrTfJ066260 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:53:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LGrTgW066259; Thu, 21 Feb 2008 09:53:29 -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.13.5/8.13.5) with SMTP id m1LGrS2P066250 for <[e-mail]>; Thu, 21 Feb 2008 09:53:28 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 28616 invoked from network); 21 Feb 2008 16:45:53 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 16:45:53 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 16:45:53 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 11:53:26 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0qak6mVcbEU9rTh+8QVQPXD0lEAAAEnJA
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "Carl Wallace" <[e-mail]>, "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LGrT2P066253
Sender: [e-mail]
Precedence: 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,

The I-D is written with the intent that all these processing is done by
the relying party during path validation.

None of this is required (per this I-D) during certificate minting,
albeit that will be a good idea.

If you agree, we will be happy to make the crystal clear although I
recall going through significant pain to just do that prior to the
publication of the I-D.  If you point out what parts of the I-D lead to
this confusion, I will be happy to modify it accordingly.

-----Original Message-----
From: David A. Cooper [mailto:[e-mail]] 
Sent: Thursday, February 21, 2008 11:49 AM
To: Santosh Chokhani
Cc: Carl Wallace; pkix
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID

Santosh,

I do not understand what you are trying to say.  There is a big 
difference between a CA using the contents of a self-signed certificate 
to impose constraints on itself and a relying party using an input to 
the path validation algorithm to impose constraints.

Are these constraints imposed by the relying party or by the CA that is 
being used by the relying party as a trust anchor? 

Santosh Chokhani wrote:
> David,
>
> We require the constraint to be imposed.
>
> What the I-D has and what you propose will result in the same answer
> assuming constraint is imposed.
>
> -----Original Message-----
> From: [e-mail]
[mailto:[e-mail]]
> On Behalf Of David A. Cooper
> Sent: Thursday, February 21, 2008 10:32 AM
> To: Carl Wallace
> Cc: pkix
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
> Carl,
>
> I agree with you that a relying party may wish to impose certain 
> constraints.  However, this draft talks about including the 
> CAClearanceConstraints extension in trust anchor certificates and then

> using the contents of that extension to initialize a path processing 
> state variable.  This is a CA placing a constraints extension in a 
> self-signed certificate to constrain itself.
>
> Section 4.1.1 of the draft says that the processing is presented as 
> additions to the path processing algorithm in RFC 3280.  If the intent

> is as you suggest, then the draft should specify 
> initial-clearance-constraints as a new input to the path processing 
> algorithm, which are used to initialize clearance related state 
> variables.  This would be consistent with RFC 3280 and would make it 
> clear that the relying party may impose initial constraints.
>
> Dave
>
> Carl Wallace wrote:
>   
>> <snip>
>>
>> P.S. I also do not understand the reason for including the
>> CAClearanceConstraints extensions in a trust anchor certificate.  If
a
>> CA wants to effectively impose such constraints, shouldn't it include
>> the constraint information in all (non-self-issued) CA certificates
>>     
> that
>   
>> it issues.  As for end entity certificates, the CA can constrain
>>     
> itself
>   
>> by simply not issuing any certificates that violate the constraint.
>>
>> [CRW] This could be categorized as associated data for a TA.  Similar
>>     
> to
>   
>> certificate policies or name constraints, a TA may act more broadly
>>     
> than
>   
>> a relying party wishes to accept when using that TA to validate
>> something.
>>     
>
>
>   




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGn3ns065391 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:49:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LGn3Vo065390; Thu, 21 Feb 2008 09:49:03 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGn1bJ065378 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 09:49:02 -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 m1LGmsoi001324; Thu, 21 Feb 2008 11:48:54 -0500
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 m1LGmhWt000657; Thu, 21 Feb 2008 11:48:44 -0500
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 11:48:41 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: Santosh Chokhani <[e-mail]>
CC: Carl Wallace <[e-mail]>, pkix <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-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>

Santosh,

I do not understand what you are trying to say.  There is a big 
difference between a CA using the contents of a self-signed certificate 
to impose constraints on itself and a relying party using an input to 
the path validation algorithm to impose constraints.

Are these constraints imposed by the relying party or by the CA that is 
being used by the relying party as a trust anchor? 

Santosh Chokhani wrote:
> David,
>
> We require the constraint to be imposed.
>
> What the I-D has and what you propose will result in the same answer
> assuming constraint is imposed.
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]]
> On Behalf Of David A. Cooper
> Sent: Thursday, February 21, 2008 10:32 AM
> To: Carl Wallace
> Cc: pkix
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
> Carl,
>
> I agree with you that a relying party may wish to impose certain 
> constraints.  However, this draft talks about including the 
> CAClearanceConstraints extension in trust anchor certificates and then 
> using the contents of that extension to initialize a path processing 
> state variable.  This is a CA placing a constraints extension in a 
> self-signed certificate to constrain itself.
>
> Section 4.1.1 of the draft says that the processing is presented as 
> additions to the path processing algorithm in RFC 3280.  If the intent 
> is as you suggest, then the draft should specify 
> initial-clearance-constraints as a new input to the path processing 
> algorithm, which are used to initialize clearance related state 
> variables.  This would be consistent with RFC 3280 and would make it 
> clear that the relying party may impose initial constraints.
>
> Dave
>
> Carl Wallace wrote:
>   
>> <snip>
>>
>> P.S. I also do not understand the reason for including the
>> CAClearanceConstraints extensions in a trust anchor certificate.  If a
>> CA wants to effectively impose such constraints, shouldn't it include
>> the constraint information in all (non-self-issued) CA certificates
>>     
> that
>   
>> it issues.  As for end entity certificates, the CA can constrain
>>     
> itself
>   
>> by simply not issuing any certificates that violate the constraint.
>>
>> [CRW] This could be categorized as associated data for a TA.  Similar
>>     
> to
>   
>> certificate policies or name constraints, a TA may act more broadly
>>     
> than
>   
>> a relying party wishes to accept when using that TA to validate
>> something.
>>     
>
>
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGZ3WP063001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:35:03 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LGZ3L0063000; Thu, 21 Feb 2008 09:35:03 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGZ1m2062993 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 09:35:03 -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 m1LGYrqU026584; Thu, 21 Feb 2008 11:34:54 -0500
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 m1LGYh18023867; Thu, 21 Feb 2008 11:34:43 -0500
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 11:34:40 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: "Turner, Sean P." <[e-mail]>
CC: [e-mail]
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <007801c8742b$af3f8310$0301a8c0@Wylie>
In-Reply-To: <007801c8742b$af3f8310$0301a8c0@Wylie>
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>

I can't comment on all of the drafts that you mention, but I am familiar 
with RFC 3280 and RFC 5055.

In the case of the certificatePolicies extension in RFC 3280, the path 
validation algorithm completely specifies how to process the extension.  
Code can be developed for CAs to include the extension in certificates 
and in relying parties to process the extension without any pre-existing 
knowledge about what policy OIDs may be included in the extension. While 
the syntax of policy qualifiers is open ended and each qualifier could 
have its own processing rules, RFC 3280 clearly discourages the use of 
policy qualifiers and further recommends that if they are included that 
only the two qualifiers defined in the document (along with processing 
rules) be used.

Similarly, while new name forms could be defined for inclusion in the 
otherName field of GeneralName and new processing rules could be defined 
for these name forms when they appear in a nameConstraints extension, 
RFC 3280 defines the processing rules for several of the name forms in 
GeneralName.  This makes it possible to use the nameConstraints 
extension in a way that permits interoperability even though the 
extension leaves room for future extensibility.

ValidationPolicy in RFC 5055 is similar.  ValidationPolicy simply allows 
a set of values to be associated with a single OID.  That means that in 
order to use a ValidationPolicy, both the client and server need to 
configured with the OID and the associated parameter values.  But, this 
is a configuration issue not an implementation issue.  Someone 
implementing the SCVP protocol does need to know about all of the 
ValidationPolicy OIDs that might be used since validation policies only 
specify input values not unique processing rules.  The person 
implementing SCVP simply needs to allow for the ability to read in 
information about validation policies from a configuration file.  While 
one part of the validation policy is the validation algorithm, and that 
certainly does include processing rules, SCVP defines two validation 
algorithms and in most cases it should be sufficient for the implementor 
to only write code to support these two validation algorithms.

Perhaps there is a middle ground in terms of the CAClearanceConstraints 
extension.  Santosh said:
> In terms of security categories, we have exposure to some "security
> policies" where some categories are restrictive and hence intersection
> is appropriate and some are permissive and hence union is appropriate.
> That is why we did not write the rules.

If this means that there will only be two possible processing rules for 
calculating securityCategories intersections, then the draft could 
specify those two processing rules.  At least then, adding support for 
new security policies could be accomplished by adding information about 
a security policy to a configuration file to indicate which of the two 
processing rules should be used when processing the 
CAClearanceConstraints extension.  Currently the draft implies that 
there may be as many processing rules as there are security policies, 
which would mean new coding would be needed to add support for each 
additional policy.

At the moment, there is simply a big whole in the draft that makes it 
unimplementable by those who are reading the draft since there is a step 
in the processing algorithm that is left unspecified.  While the authors 
may have exposure to some security policies and may know 
securityCategories intersections should be processed for those security 
policies, what about everyone else reading the draft?

Dave

Turner, Sean P. wrote:
>>>> 4 - With the proposed definition of the constraints, no 
>>>>         
>> standard code 
>>     
>>>> would be available, since the details of the securityCategory field 
>>>> would be left undefined. One main goal of RFCs is to allow for 
>>>> interoperability testing.
>>>>     
>>>>         
>>> So there are other standards that have essentially ANYs in 
>>>       
>> them where 
>>     
>>> interoperability was achieved I believe we can do the same 
>>>       
>> thing here. 
>>     
>>> There is an ISO standard (ISO 15816) that defines categories, but 
>>> honestly I'd like to decouple that discussion from this discussion.
>>>   
>>>       
>> The processing rules for the CAClearanceConstraints extension 
>> includes the following rule:
>>
>>       -- Calculate securityCategories intersection in accordance with
>>          guidelines associated with the security policy represented by
>>          the policyID.
>>
>> Why do you believe that it is reasonable to publish this draft 
>> with such an incomplete processing rule included?  How do you 
>> expect people to implement this CAClearanceConstraints extension?
>>
>> Is there an assumption that inclusion of securityCategories in 
>> CAClearanceConstraints extensions will be rare and so it is 
>> acceptable for a generic implementation to simply reject 
>> certification paths that include a CAClearanceConstraints 
>> extension with securityCategories?  
>>     
>
> I think it's reasonable because there are many RFC that publish without
> complete policy definitions or requirements (and I agree with why it's done
> ... but we're just another one of them).
>
> I'd say the number of CAs that will issue clearances or include
> CAClearanceConstraints will small compared to those that don't. I suspect
> that most policies probably won't need categories, they could do it with the
> classList.
>
>   
>> Alternatively, do you expect that there will be a limited 
>> number of security policies and there is a plan to publish a 
>> second document that lists these security policies along with 
>> the rules for performing the above calculation for each of the 
>> security policies?
>>     
>
> The answer may well depend on whether this ID gets published ;) but I'd not
> expect a huge amount of policies - based on the fact that not a lot of
> people implmement security labels/clearances. Maybe NIST will do one?
>
>   
>> You say that other standards do something similar.  Can you 
>> point to specific examples where a standard has been approved 
>> despite leaving things as open ended as this?
>>     
>
> This is where we get in to the you say interop and I say interop. I'm not
> sure what you mean by "as open ended as this" but if I look for ANYs or any
> where there's an undefined policy (I'm not trying to start a flame war or
> open old wounds here):
>
> PKIX:
>
> RFC 3161 - TSAPolicyId - Is required but there's no required OID or the
> defaults it says that must be defined.
>
> RFC 3280 - Certificate Policies - CAs and applications are required to
> support, but there's no required policy OID to include.
>
> RFC 3281 - No attributes are required to be conveyed.
>          - Clearance - uses the same syntax as our ID.
>
> RFC 5055 - ValidationPolicy - Required as part of Querry with no MUST policy
> OID and not requirements for the mandatory defaults.
>
> S/MIME:
>
> RFC 2634 - ESS Security Label - uses syntax similar to our ID.
>
> I'm sure there are more.
>
> Maybe this RFC motivates implementors to start supporting these two
> extensions in their products because they see there's a market. Maybe all
> the fields get supported - maybe not. The next step in the standardization
> process determines what fields get culled.
>
> spt
>   



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGXUn5062891 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:33:30 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LGXU7b062890; Thu, 21 Feb 2008 09:33:30 -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.13.5/8.13.5) with ESMTP id m1LGXSgZ062884 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 09:33:29 -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.240.5; Thu, 21 Feb 2008 16:33:27 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C303.europe.corp.microsoft.com ([65.53.213.93]) with mapi; Thu, 21 Feb 2008 16:33:27 +0000
From: Stefan Santesson <[e-mail]>
To: Stephen Kent <[e-mail]>, Peter Gutmann <[e-mail]>
CC: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 21 Feb 2008 16:33:26 +0000
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Thread-Topic: Wildcard DNS. Re: rfc 3280bis
Thread-Index: AchwPYA+Tw5egkrdRRefXBDJQ1qGLAEaGnJA
Message-ID: <[e-mail]>
References: <[e-mail]> <p06240506c3dbe36c40a5@[192.168.163.192]>
In-Reply-To: <p06240506c3dbe36c40a5@[192.168.163.192]>
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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LGXTgY062885
Sender: [e-mail]
Precedence: 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 gets to the core of the problem:

> Since the real world is full of broken CA behavior, as you have
> personally document through a multi-year collection of non-compliant
> certs, a note explaining various degrees of brokenness would indeed
> be very long.  It also has no place in this document.  Maybe you
> should submit an April 1st RFC on the topic.

However, let's sort the rotten fruit in the basket a bit.

There are tons of bad certificates out there, but most of them belongs in local PKI deployment where a local application have learned to understand the obscure output of a local CA. In such case no or little harm is made to the global community and standard products. The local implementation will simply have to choose between changing their use of PKI or manually tweak every new application making use of certs.

We have only one successful deployment of public certificates, being server SSL/TLS certificates. Those using it, issuing certificates for it and developing applications and browsers using it, are not evil people with an evil agenda. They simply want to make it work. To make it work, they need to take the behavior of others into the calculation which includes interworking with a huge base of existing certificates and applications.

Making it work is far more important than being faithful to any standard. Sad maybe, but it's a fact of life.

This means that no matter how much we may dislike it, the community out there will still issue server certificates with dns names in the common name field and they will produce certificates with wildcards in the dns name.

We can simply choose to ignore it or acknowledge it, but we can't change it.
However we do not have to standardize it. But we may want to document it. This is what Informational RFCs are there for.

I'm supportive of an effort to document this in an IETF document.

Stefan Santesson
Senior Program Manager
Windows Security, Standards


> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Stephen Kent
> Sent: den 16 februari 2008 01:52
> To: Peter Gutmann
> Cc: [e-mail]; [e-mail]
> Subject: Re: Wildcard DNS. Re: rfc 3280bis
>
>
> At 2:14 AM +1300 2/16/08, Peter Gutmann wrote:
> >Stephen Kent <[e-mail]> writes:
> >
> >>RFC 3280, which superseded 2459, removed the reference to wildcard
> characters
> >>in SANs, making it clear that they were no longer acceptable.  3280
> was
> >>published in 2002, 5.5 years ago.
> >
> >Now all we need to do is convince every CA on the planet to stop
> issuing
> >wildcard certificates.  Who wants to have a go first?
>
> not EVERY CA issues such certs. since the notification problem is
> thus not nearly so great as you suggest, I'm willing to delegate this
> awesome responsibility to you.
>
> >
> >>I agree that 2818 should be revised, given that the reference it
> makes to the
> >>PKIX cert profile is now 2 revs (.5. years) out of date, and no
> longer valid.
> >
> >Perhaps 2818bis could contain a note for implementors mapping what the
> RFCs
> >say to what the world really does.
> >
> >(I suspect it'd be quite a long note).
>
> Since the real world is full of broken CA behavior, as you have
> personally document through a multi-year collection of non-compliant
> certs, a note explaining various degrees of brokenness would indeed
> be very long.  It also has no place in this document.  Maybe you
> should submit an April 1st RFC on the topic.
>
> Steve




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LGPVq7062188 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:25:31 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LGPV97062187; Thu, 21 Feb 2008 09:25:31 -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.13.5/8.13.5) with SMTP id m1LGPTxv062179 for <[e-mail]>; Thu, 21 Feb 2008 09:25:30 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 32122 invoked from network); 21 Feb 2008 16:25:29 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.10.201 with login) by smtp104.biz.mail.re2.yahoo.com with SMTP; 21 Feb 2008 16:25:29 -0000
X-YMail-OSG: KWeTLlcVM1kNJx1NZCvf0SnfrCDiWDs3Jnrej7jALxBndAWwAH07Wz6oY9nvyV8XdVZrefrVijxBD1YV2Ds7OVhmrre4FT8Ms5aNPVIi2_SfRnIRcCW5JITU8hBCY3GR1aMOgUnc.g54388-
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: "'David A. Cooper'" <[e-mail]>
Cc: "'pkix'" <[e-mail]>
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <007801c8742b$af3f8310$0301a8c0@Wylie> <[e-mail]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 11:18:27 -0500
Organization: IECA, Inc.
Message-ID: <00a401c874a5$640eda60$0301a8c0@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.3198
in-reply-to: <[e-mail]>
Thread-Index: Ach0oocW9aEqpGcGTBKn7FRqH6mvagAANZ7w
Sender: [e-mail]
Precedence: 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,

We followed the example set by Stefan in the S/MIME Capabilities certificate
extension that uses an attribute's syntax as an extension's syntax. The
outcome of the discussion was that you didn't need to define a new structure
and that you could reuse the syntax because (to loosely paraphrase the
outcome of the discussions) you'll know it's an extension from context.

spt

>-----Original Message-----
>From: David A. Cooper [mailto:[e-mail]] 
>Sent: Thursday, February 21, 2008 10:58 AM
>To: Turner, Sean P.
>Cc: pkix
>Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>Turner, Sean P. wrote:
>>> I do not understand why this draft specifies that this attribute 
>>> should be encoded as an extension.  The clearance attribute is 
>>> defined as an Attribute.  The subjectDirectoryAttributes extension 
>>> was defined for the specific purpose of allowing attributes to be 
>>> included in certificates.
>>> X.501, which defines the clearance attribute, states that if a 
>>> clearance attribute is to be included in a public key 
>certificate, it 
>>> should be placed in the subjectDirectoryAttributes extension.
>>>
>>> Why do people feel that there is a compelling reason to avoid using 
>>> the subjectDirectoryAttributes extension when encoding an attribute 
>>> in an extension?
>>>     
>>
>> X.501 says "The clearance can be bound to the Distinguished Name of 
>> the requestor through a certificate extension field (subject 
>Directory
>> attribute) or through an attribute certificate." This might be picky 
>> but that's not a MUST/SHALL or even a SHOULD for either. 
>(some or many 
>> may disagree with the following) I think people don't like 
>SDA because 
>> it's optional in RFC3280 - which basically means 
>unsupported. Now you 
>> can argue that adding a new attribute or a new extension still means 
>> it's all unsupported but at least if you define your own 
>extension you 
>> can pick whether you want criticality (note we always want clearance 
>> to be
>> non-critical) and you don't have to carry the extra OID and SEQUENCE 
>> wrappers.
>>   
>
>I think it is pretty clear from both the language of X.501 and 
>the syntax of the clearance attribute (compare the syntax for 
>the clearance attribute with the syntax used for extensions):
>                clearance ATTRIBUTE ::= {
>
>                keyUsage EXTENSION ::= {
>
>What you are doing is effectively creating a new certificate 
>extension and assigning it an OID that has already been 
>assigned to an existing attribute.  If you wish to use the 
>existing OID, then you should profile the attribute assigned 
>to that OID not define something new.  At the moment, there 
>doesn't seem to be a need to define a new extension whose 
>syntax is nearly identical to that of an existing attribute 
>when the draft could just profile the use of the attribute.  
>Arguing that a new extension is needed since support for the 
>subjectDirectoryAttributes extension is option is hardly 
>compelling.  Anyone that wants to support the clearance 
>attribute will need to support the subjectDirectoryAttributes 
>extension, just as they would if they wanted to support the 
>attributes in RFC 3739.  The subjectDirectoryAttributes 
>extension is not a very complex extension to process.
>
>
>Dave
>



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LG7FCT060469 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:07:15 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LG7Foq060468; Thu, 21 Feb 2008 09:07:15 -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.13.5/8.13.5) with ESMTP id m1LG7DNv060461 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 09:07:14 -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.240.5; Thu, 21 Feb 2008 16:07:12 +0000
Received: from EA-EXMSG-C332.europe.corp.microsoft.com ([65.53.221.79]) by DUB-EXHUB-C302.europe.corp.microsoft.com ([65.53.213.92]) with mapi; Thu, 21 Feb 2008 16:07:12 +0000
From: Stefan Santesson <[e-mail]>
To: Russ Housley <[e-mail]>, "[e-mail]" <[e-mail]>
Date: Thu, 21 Feb 2008 16:07:11 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: AchVQOG5UgddOVvDQg+e41vGLubOBAfYRucg
Message-ID: <[e-mail]>
References: <006001c85495$093074d0$0301a8c0@Wylie> <[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"
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LG7ENu060463
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

First I want to apologize for a somewhat late response to this issue. I have been away from work due to my mother's passing but I'm now fully back and operational.

I'm somewhat surprised to see such overwhelming support for this draft. Personally I have some big concerns.

Including authorization and clearance information in certificates is both tricky and dangerous. In my opinion certificates is the least suitable place for such information.
Clearance is not just tied to a person, but to systems and I may have a wide range of clearances in different systems. Clearance may change very rapidly while certificates and more static declarations of the relationship between a person and a set of keys. So they do not naturally mix very well.

Further, the extension of this draft affects path validation. This means that supporting this extension involves a HUGE commitment from product development compared to an extension that is only parsed locally in the relying party's application. An extension that is processed in path validation requires not only changes to the path validation algorithm. It will also require API changes to accommodate status and error codes as well as results.

I don't find any motivation for this new standard that makes me believe that it is worth the effort and I therefore object to this being adopted as a PKIX work item.


Stefan Santesson
Senior Program Manager
Windows Security, Standards

> -----Original Message-----
> From: [e-mail] [mailto:owner-ietf-
> [e-mail]] On Behalf Of Russ Housley
> Sent: den 12 januari 2008 15:18
> To: [e-mail]
> Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
>
>
> While this extension is primarily useful to a Government/Military
> environment, it does have some applicability to commercial
> environments too.  This situation is demonstrated in RFC 3114.  I see
> advantages to all of the potential users if this specification is
> published on the IETF standards-track.
>
> I encourage the PKIX WG to accept this document.
>
> Russ
>
> At 04:00 PM 1/11/2008, Turner, Sean P. wrote:
>
> >Santosh Chokhani and I have produced an ID that defines an extension
> that
> >holds a subject's clearance. The ID also defines an extension called
> >clearance constraints to limit the clearance values a CA should place
> in
> >subordinate certificates. Finally, it defines the certification path
> >processing rules to determine the clearances for the subject of the
> >certificate based on the clearance and clearance constraints asserted
> in the
> >certification path. The ID can be found at:
> >
> >http://www.ietf.org/internet-drafts/draft-turner-
> caclearanceconstraints-00.t
> >xt
> >
> >We're hoping that PKIX would be willing to adopt this as a work item.
> >
> >spt




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LG7AL2060457 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 09:07:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LG7Alq060456; Thu, 21 Feb 2008 09:07: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.13.5/8.13.5) with SMTP id m1LG79GD060441 for <[e-mail]>; Thu, 21 Feb 2008 09:07:10 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 28168 invoked from network); 21 Feb 2008 15:59:35 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 15:59:35 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 15:59:34 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 11:07:08 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0oqWLJXL2NqLrRFqBYAZc3V/WuwAAPSSg
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Santosh Chokhani" <[e-mail]>
To: "David A. Cooper" <[e-mail]>, "Carl Wallace" <[e-mail]>
Cc: "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LG7AGD060451
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

David,

We require the constraint to be imposed.

What the I-D has and what you propose will result in the same answer
assuming constraint is imposed.

-----Original Message-----
From: [e-mail] [mailto:[e-mail]]
On Behalf Of David A. Cooper
Sent: Thursday, February 21, 2008 10:32 AM
To: Carl Wallace
Cc: pkix
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID


Carl,

I agree with you that a relying party may wish to impose certain 
constraints.  However, this draft talks about including the 
CAClearanceConstraints extension in trust anchor certificates and then 
using the contents of that extension to initialize a path processing 
state variable.  This is a CA placing a constraints extension in a 
self-signed certificate to constrain itself.

Section 4.1.1 of the draft says that the processing is presented as 
additions to the path processing algorithm in RFC 3280.  If the intent 
is as you suggest, then the draft should specify 
initial-clearance-constraints as a new input to the path processing 
algorithm, which are used to initialize clearance related state 
variables.  This would be consistent with RFC 3280 and would make it 
clear that the relying party may impose initial constraints.

Dave

Carl Wallace wrote:
> <snip>
>
> P.S. I also do not understand the reason for including the
> CAClearanceConstraints extensions in a trust anchor certificate.  If a
> CA wants to effectively impose such constraints, shouldn't it include
> the constraint information in all (non-self-issued) CA certificates
that
> it issues.  As for end entity certificates, the CA can constrain
itself
> by simply not issuing any certificates that violate the constraint.
>
> [CRW] This could be categorized as associated data for a TA.  Similar
to
> certificate policies or name constraints, a TA may act more broadly
than
> a relying party wishes to accept when using that TA to validate
> something.




Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LFw1BF059246 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 08:58:01 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LFw1fG059245; Thu, 21 Feb 2008 08:58: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.nist.gov (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LFvxp9059237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 08:58:00 -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 m1LFvrPL008273; Thu, 21 Feb 2008 10:57:53 -0500
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 m1LFvggx031350; Thu, 21 Feb 2008 10:57:43 -0500
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 10:57:40 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: "Turner, Sean P." <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <007801c8742b$af3f8310$0301a8c0@Wylie>
In-Reply-To: <007801c8742b$af3f8310$0301a8c0@Wylie>
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>

Turner, Sean P. wrote:
>> I do not understand why this draft specifies that this 
>> attribute should be encoded as an extension.  The clearance 
>> attribute is defined as an Attribute.  The 
>> subjectDirectoryAttributes extension was defined for the 
>> specific purpose of allowing attributes to be included in 
>> certificates.  
>> X.501, which defines the clearance attribute, states that if a 
>> clearance attribute is to be included in a public key 
>> certificate, it should be placed in the 
>> subjectDirectoryAttributes extension.
>>
>> Why do people feel that there is a compelling reason to avoid 
>> using the subjectDirectoryAttributes extension when encoding 
>> an attribute in an extension?
>>     
>
> X.501 says "The clearance can be bound to the Distinguished Name of the
> requestor through a certificate extension field (subject Directory
> attribute) or through an attribute certificate." This might be picky but
> that's not a MUST/SHALL or even a SHOULD for either. (some or many may
> disagree with the following) I think people don't like SDA because it's
> optional in RFC3280 - which basically means unsupported. Now you can argue
> that adding a new attribute or a new extension still means it's all
> unsupported but at least if you define your own extension you can pick
> whether you want criticality (note we always want clearance to be
> non-critical) and you don't have to carry the extra OID and SEQUENCE
> wrappers.
>   

I think it is pretty clear from both the language of X.501 and the 
syntax of the clearance attribute (compare the syntax for the clearance 
attribute with the syntax used for extensions):
                clearance ATTRIBUTE ::= {

                keyUsage EXTENSION ::= {

What you are doing is effectively creating a new certificate extension 
and assigning it an OID that has already been assigned to an existing 
attribute.  If you wish to use the existing OID, then you should profile 
the attribute assigned to that OID not define something new.  At the 
moment, there doesn't seem to be a need to define a new extension whose 
syntax is nearly identical to that of an existing attribute when the 
draft could just profile the use of the attribute.  Arguing that a new 
extension is needed since support for the subjectDirectoryAttributes 
extension is option is hardly compelling.  Anyone that wants to support 
the clearance attribute will need to support the 
subjectDirectoryAttributes extension, just as they would if they wanted 
to support the attributes in RFC 3739.  The subjectDirectoryAttributes 
extension is not a very complex extension to process.


Dave



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LFfw9f057606 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 08:41:58 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LFfwLs057605; Thu, 21 Feb 2008 08:41: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.13.5/8.13.5) with SMTP id m1LFfs5U057598 for <[e-mail]>; Thu, 21 Feb 2008 08:41:57 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 27889 invoked from network); 21 Feb 2008 15:34:20 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 15:34:20 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 15:34:20 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 10:41:53 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0nuviH4ed0HdTRbCJ2lt0NxI1jwAARstQ
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <[e-mail]> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "David A. Cooper" <[e-mail]>
Cc: "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LFfv5U057600
Sender: [e-mail]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[e-mail]?body=unsubscribe>

Section 4.1.1 of the draft says that the processing is presented as
additions to the path processing algorithm in RFC 3280.  If the intent
is as you suggest, then the draft should specify
initial-clearance-constraints as a new input to the path processing
algorithm, which are used to initialize clearance related state
variables.  This would be consistent with RFC 3280 and would make it
clear that the relying party may impose initial constraints.

[CRW] This sounds right to me, with the inclusion of the value as an
extension or "associated data" simply being a mechanism to populate the
input to the path validation engine.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LFWAOO056797 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 08:32:10 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LFWAHv056796; Thu, 21 Feb 2008 08:32:10 -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 (rimp1.nist.gov [129.6.16.226]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LFW9RZ056790 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <[e-mail]>; Thu, 21 Feb 2008 08:32:10 -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 m1LFW2rr025146; Thu, 21 Feb 2008 10:32:03 -0500
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 m1LFVu0R013976; Thu, 21 Feb 2008 10:31:56 -0500
Message-ID: <[e-mail]>
Date: Thu, 21 Feb 2008 10:31:54 -0500
From: "David A. Cooper" <[e-mail]>
User-Agent: Thunderbird 2.0.0.6 (X11/20070914)
MIME-Version: 1.0
To: Carl Wallace <[e-mail]>
CC: pkix <[e-mail]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]> <[e-mail]>
In-Reply-To: <[e-mail]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-NIST-MailScanner-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>

Carl,

I agree with you that a relying party may wish to impose certain 
constraints.  However, this draft talks about including the 
CAClearanceConstraints extension in trust anchor certificates and then 
using the contents of that extension to initialize a path processing 
state variable.  This is a CA placing a constraints extension in a 
self-signed certificate to constrain itself.

Section 4.1.1 of the draft says that the processing is presented as 
additions to the path processing algorithm in RFC 3280.  If the intent 
is as you suggest, then the draft should specify 
initial-clearance-constraints as a new input to the path processing 
algorithm, which are used to initialize clearance related state 
variables.  This would be consistent with RFC 3280 and would make it 
clear that the relying party may impose initial constraints.

Dave

Carl Wallace wrote:
> <snip>
>
> P.S. I also do not understand the reason for including the
> CAClearanceConstraints extensions in a trust anchor certificate.  If a
> CA wants to effectively impose such constraints, shouldn't it include
> the constraint information in all (non-self-issued) CA certificates that
> it issues.  As for end entity certificates, the CA can constrain itself
> by simply not issuing any certificates that violate the constraint.
>
> [CRW] This could be categorized as associated data for a TA.  Similar to
> certificate policies or name constraints, a TA may act more broadly than
> a relying party wishes to accept when using that TA to validate
> something.



Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LDSHT8042637 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 21 Feb 2008 06:28:17 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1LDSHEv042636; Thu, 21 Feb 2008 06:28:17 -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.13.5/8.13.5) with SMTP id m1LDSGqh042628 for <[e-mail]>; Thu, 21 Feb 2008 06:28:16 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 26621 invoked from network); 21 Feb 2008 13:20:41 -0000
Received: from [e-mail] by scygmxsecs1.cygnacom.com with EntrustECS-Server-7.4;21 Feb 2008 13:20:41 -0000
Received: from unknown (HELO scygexch1.cygnacom.com) (10.60.50.8) by scygmxsecs1.cygnacom.com with SMTP; 21 Feb 2008 13:20:41 -0000
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
X-MimeOLE: Produced By Microsoft Exchange V6.5
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 08:28:14 -0500
Message-ID: <[e-mail]>
in-reply-to: <[e-mail]>
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
Thread-Topic: Clearance & CA Clearance Constraints Cert Ext ID
Thread-Index: Ach0DcREqk1ogZGJQeeIOs6Zuahj9gAf5YHg
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]>
From: "Carl Wallace" <[e-mail]>
To: "pkix" <[e-mail]>
Content-Transfer-Encoding: 8bit
X-MIME-Autoconverted: from quoted-printable to 8bit by balder-227.proper.com id m1LDSHqh042631
Sender: [e-mail]
Precedence: 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>

P.S. I also do not understand the reason for including the
CAClearanceConstraints extensions in a trust anchor certificate.  If a
CA wants to effectively impose such constraints, shouldn't it include
the constraint information in all (non-self-issued) CA certificates that
it issues.  As for end entity certificates, the CA can constrain itself
by simply not issuing any certificates that violate the constraint.

[CRW] This could be categorized as associated data for a TA.  Similar to
certificate policies or name constraints, a TA may act more broadly than
a relying party wishes to accept when using that TA to validate
something.  



Received: from infokor.static.otenet.gr (infokor.static.otenet.gr [83.235.172.114]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1LBSCQq028992 for <[e-mail]>; Thu, 21 Feb 2008 04:28:13 -0700 (MST) (envelope-from [e-mail])
Message-ID: <000801c8747c$d912bdf0$72aceb53@kpn6>
From: "Maritsa Bornzin" <[e-mail]>
To: [e-mail]
Subject: Great bedroom stories start with this.
Date: Thu, 21 Feb 2008 13:28:14 +0200
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="--------=_NextPart_000_0004_01C8748D.9C9B8DF0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3198
X-Antivirus: avast! (VPS 080220-0, 20/02/2008), Outbound message
X-Antivirus-Status: Clean

----------=_NextPart_000_0004_01C8748D.9C9B8DF0
Content-Type: text/plain;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

You and your almighty rod of pleasure.
----------=_NextPart_000_0004_01C8748D.9C9B8DF0
Content-Type: text/html;
        charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2900.3199" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<A href=3D"http://www.geriteain.com/">You and your almighty rod of=20
pleasure.</A></BODY></HTML>
----------=_NextPart_000_0004_01C8748D.9C9B8DF0--


Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.13.5/8.13.5) with ESMTP id m1L1sI01075002 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 20 Feb 2008 18:54:18 -0700 (MST) (envelope-from [e-mail])
Received: (from majordom@localhost) by balder-227.proper.com (8.13.5/8.13.5/Submit) id m1L1sIBP075001; Wed, 20 Feb 2008 18:54:18 -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.13.5/8.13.5) with SMTP id m1L1sHaj074994 for <[e-mail]>; Wed, 20 Feb 2008 18:54:18 -0700 (MST) (envelope-from [e-mail])
Received: (qmail 64112 invoked from network); 21 Feb 2008 01:54:16 -0000
Received: from unknown (HELO Wylie) ([e-mail]@96.241.8.163 with login) by smtp105.biz.mail.re2.yahoo.com with SMTP; 21 Feb 2008 01:54:16 -0000
X-YMail-OSG: RgxsvtMVM1laek0lxedGrxln.AIVMPcvOgqOOQ_B6AV.9CE5udtvI6sYzwNqX7Nre7gQe7kOEw--
X-Yahoo-Newman-Property: ymail-3
From: "Turner, Sean P." <[e-mail]>
To: <[e-mail]>
References: <[e-mail]> <026501c873e6$c819de70$0301a8c0@Wylie> <[e-mail]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Wed, 20 Feb 2008 20:47:14 -0500
Organization: IECA, Inc.
Message-ID: <007801c8742b$af3f8310$0301a8c0@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.3198
In-Reply-To: <[e-mail]>
Thread-Index: Ach0EQP53vdZMipTQ7m2FrAbcjaAOQABAgww
Sender: [e-mail]
Precedence: 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,

Comments in line...

spt

>-----Original Message-----
>> We followed in Stefan's footsteps [RFC 4262] where an attribute
>> (SMIMECapabilities) got turned in to an extension. The precedent has 
>> been set we just followed it. I don't think we need to look at RFC 
>> 3281 to say where the information can or can't go. X.501 and other 
>> places where sytnax is defined doesn't say where all the info can go.
>>   
>
>When I scanned this document some time ago, I was unsure how 
>one was expected to include clearance information in a 
>certificate.  Section 2 of the draft begins:
>
>   The Clearance certificate extension in a certificate indicates the
>   clearances held by the subject.  It uses the clearance attribute
>   syntax from Section 4.4.6 of [RFC3281] in the Subject Directory
>   Attributes extension.  The Clearance certificate extension 
>MUST never
>   be marked critical.
>
>The statement about criticality implied that this was an 
>extension, but the second sentence suggested that it should 
>appear in the subjectDirectoryAttributes extension.

Sorry about the confusion. In the next version we'll delete the "in the
Subject Directory Attributes extension." We were proposing it as a
standalone extension.

>I do not understand why this draft specifies that this 
>attribute should be encoded as an extension.  The clearance 
>attribute is defined as an Attribute.  The 
>subjectDirectoryAttributes extension was defined for the 
>specific purpose of allowing attributes to be included in 
>certificates.  
>X.501, which defines the clearance attribute, states that if a 
>clearance attribute is to be included in a public key 
>certificate, it should be placed in the 
>subjectDirectoryAttributes extension.
>
>Why do people feel that there is a compelling reason to avoid 
>using the subjectDirectoryAttributes extension when encoding 
>an attribute in an extension?

X.501 says "The clearance can be bound to the Distinguished Name of the
requestor through a certificate extension field (subject Directory
attribute) or through an attribute certificate." This might be picky but
that's not a MUST/SHALL or even a SHOULD for either. (some or many may
disagree with the following) I think people don't like SDA because it's
optional in RFC3280 - which basically means unsupported. Now you can argue
that adding a new attribute or a new extension still means it's all
unsupported but at least if you define your own extension you can pick
whether you want criticality (note we always want clearance to be
non-critical) and you don't have to carry the extra OID and SEQUENCE
wrappers.

>>> 4 - With the proposed definition of the constraints, no 
>standard code 
>>> would be available, since the details of the securityCategory field 
>>> would be left undefined. One main goal of RFCs is to allow for 
>>> interoperability testing.
>>>     
>>
>> So there are other standards that have essentially ANYs in 
>them where 
>> interoperability was achieved I believe we can do the same 
>thing here. 
>> There is an ISO standard (ISO 15816) that defines categories, but 
>> honestly I'd like to decouple that discussion from this discussion.
>>   
>
>The processing rules for the CAClearanceConstraints extension 
>includes the following rule:
>
>       -- Calculate securityCategories intersection in accordance with
>          guidelines associated with the security policy represented by
>          the policyID.
>
>Why do you believe that it is reasonable to publish this draft 
>with such an incomplete processing rule included?  How do you 
>expect people to implement this CAClearanceConstraints extension?
>
>Is there an assumption that inclusion of securityCategories in 
>CAClearanceConstraints extensions will be rare and so it is 
>acceptable for a generic implementation to simply reject 
>certification paths that include a CAClearanceConstraints 
>extension with securityCategories?  

I think it's reasonable because there are many RFC that publish without
complete policy definitions or requirements (and I agree with why it's done
... but we're just another one of them).

I'd say the number of CAs that will issue clearances or include
CAClearanceConstraints will small compared to those that don't. I suspect
that most policies probably won't need categories, they could do it with the
classList.

>Alternatively, do you expect that there will be a limited 
>number of security policies and there is a plan to publish a 
>second document that lists these security policies along with 
>the rules for performing the above calculation for each of the 
>security policies?

The answer may well depend on whether this ID gets published ;) but I'd not
expect a huge amount of policies - based on the fact that not a lot of
people implmement security labels/clearances. Maybe NIST will do one?

>You say that other standards do something similar.  Can you 
>point to specific examples where a standard has been approved 
>despite leaving things as open ended as this?

This is where we get in to the you say interop and I say interop. I'm not
sure what you mean by "as open ended as this" but if I look for ANYs or any
where there's an undefined policy (I'm not trying to start a flame war or
open old wounds here):

PKIX:

RFC 3161 - TSAPolicyId - Is required but there's no required OID or the
defaults it says that must be defined.

RFC 3280 - Certificate Policies - CAs and applications are required to
support, but there's no required policy OID to include.

RFC 3281 - No attributes are required to be conveyed.
         - Clearance - uses the same syntax as our ID.

RFC 5055 - ValidationPolicy - Required as part of Querry with no MUST policy
OID and not requirements for the mandatory defaults.

S/MIME:

RFC 2634 - ESS Security Label - uses syntax similar to our ID.

I'm sure there are more.

Maybe this RFC motivates implementors to start supporting these two
extensions in their products because they see there's a market. Maybe all
the fields get supported - maybe not. The next step in the standardization
process determines what fields get culled.

spt

>Dave
>
>P.S. I also do not understand the reason for including the 
>CAClearanceConstraints extensions in a trust anchor 
>certificate.  If a CA wants to effectively impose such 
>constraints, shouldn't it include the constraint information 
>in all (non-self-issued) CA certificates that it issues.  As 
>for end entity certificates, the CA can constrain itself by 
>simply not issuing any certificates that violate the constraint.
>