Subject: Re: Wildcard DNS. Re: rfc 3280bis

From: [email-masked] (Peter Gutmann)
Date: Sat, 16 Feb 2008 02:14:59 +1300

Stephen Kent <[email-masked]> 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.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Feb 2008 19:52:06 -0500

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

---

From: [email-masked] (Peter Gutmann)
Date: Sat, 16 Feb 2008 17:37:11 +1300

Stephen Kent <[email-masked]> writes:
>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.

---

From: Stephen Kent <[email-masked]>
Date: Fri, 15 Feb 2008 23:48:00 -0500

>approximate reality, I will indeed give that a go :-).

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

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 21 Feb 2008 16:33:26 +0000

> 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: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stephen Kent
> Sent: den 16 februari 2008 01:52
> To: Peter Gutmann
> Cc: [email-masked]; [email-masked]
> Subject: Re: Wildcard DNS. Re: rfc 3280bis
>
>

---

From: "Kemp, David P." <[email-masked]>
Date: Thu, 21 Feb 2008 13:03:42 -0500

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, February 21, 2008 11:33 AM
To: Stephen Kent; Peter Gutmann
Cc: [email-masked]; [email-masked]
Subject: RE: Wildcard DNS. Re: rfc 3280bis

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.

Stefan Santesson
Senior Program Manager

> >Perhaps 2818bis could contain a note for implementors mapping what
the
> RFCs

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 21 Feb 2008 18:34:26 +0000

> toward standards compliance by enabling authors and users to recognize

I'd support documenting the de-facto situation.

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

---

From: "David A. Cooper" <[email-masked]>
Date: Thu, 21 Feb 2008 15:05:51 -0500

> 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

---

From: Philipp Gühring <[email-masked]>
Date: Fri, 22 Feb 2008 00:50:33 +0100

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.

> Sad maybe, but it's a fact of life.

Theoretically, no. Practially, yes.

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

> 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

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 22 Feb 2008 07:41:46 +0000

Hi Philipp,

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

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

> [email-masked]] On Behalf Of Philipp Gühring
> Sent: den 22 februari 2008 00:51
> To: [email-masked]
> server

---

From: "Kemp, David P." <[email-masked]>
Date: Fri, 22 Feb 2008 12:01:53 -0500

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: [email-masked] [mailto:[email-masked]] On Behalf Of Stefan Santesson
Sent: Friday, February 22, 2008 2:42 AM
To: Philipp Gühring; [email-masked]
Subject: RE: Wildcard DNS. Re: rfc 3280bis

Hi Philipp,

Stefan Santesson
Senior Program Manager

---

From: Eric Norman <[email-masked]>
Date: Fri, 22 Feb 2008 17:33:19 -0600

----- Original Message -----
From: "Kemp, David P." <[email-masked]>
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

---

From: Philipp Gühring <[email-masked]>
Date: Wed, 27 Feb 2008 02:20:44 +0100

Hi,

> 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

Yes, that´s still the case.

Best regards,
Philipp Gühring

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Wed, 20 Feb 2008 18:27:01 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Turner, Sean P." <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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.

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Date: Wed, 20 Feb 2008 18:17:39 -0500
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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>

Date: Wed, 20 Feb 2008 16:46:10 -0500
From: "David A. Cooper" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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.

From: "Turner, Sean P." <[email-masked]>
To: "'Denis Pinkas'" <[email-masked]>, <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Wed, 20 Feb 2008 12:34:01 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Denis,

Comments inline.. 

spt

>From: [email-masked] 
>[mailto:[email-masked]] On Behalf Of Denis Pinkas
>Sent: Wednesday, January 16, 2008 3:52 AM
>To: [email-masked]
>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
>
>
>

From: Stefan Santesson <[email-masked]>
To: pkix <[email-masked]>
Date: Wed, 20 Feb 2008 17:04:44 +0000
Subject: Call for agenda items, Philadelphia IETF
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

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

Date: Wed, 20 Feb 2008 12:46:39 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Sender: [email-masked]

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 
>>[email-masked] 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:
>>	[email-masked].
>>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:     <[email-masked]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

Content-class: urn:content-classes:message
Subject: RE: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Date: Tue, 19 Feb 2008 17:43:05 -0500
From: "Carl Wallace" <[email-masked]>
To: "Denis Pinkas" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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 
>[email-masked] 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:
>	[email-masked].
>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:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

From: "SIARHEI Grassetti" <[email-masked]>
To: [email-masked]
Subject: Your throbbing missile is ready to fire
Date: Tue, 19 Feb 2008 16:05:39 +0100

----------=_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--

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key  Infrastructure Certificate and Certificate Revocation List (CRL)  Profile' to Proposed Standard 
Date: Fri, 15 Feb 2008 12:04:41 -0800 (PST)
Cc: pkix mailing list <[email-masked]>, pkix chair <[email-masked]>, Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>
Sender: [email-masked]

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
[email-masked]
http://www.ietf.org/mailman/listinfo/ietf-announce

From: "Mimi krystek" <[email-masked]>
To: [email-masked]
Subject: Want to have the best sex of your life? Here's how
Date: Tue, 19 Feb 2008 14:48:27 +0100

----------=_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--

Date: Tue, 19 Feb 2008 14:03:52 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Sender: [email-masked]

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
>[email-masked] 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:
>	[email-masked].
>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:     <[email-masked]>
>
>ENCODING mime
>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

From: "gracie Decato" <[email-masked]>
To: [email-masked]
Subject: Want to be longer, thicker and harder all night long? Here's how
Date: Mon, 18 Feb 2008 19:46:54 -0600

----------=_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--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt 
Date: Mon, 18 Feb 2008 07:15:01 -0800 (PST)
Sender: [email-masked]

--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
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:     <[email-masked]>

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

From: "Kolonitskiy Leon" <[email-masked]>
To: [email-masked]
Subject: Your best present to her is your long hard rod.
Date: Mon, 18 Feb 2008 11:34:55 +0100

----------=_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--

From: "Joost Krishnan" <[email-masked]>
To: [email-masked]
Subject: Those locker room stares will be for the right reason.
Date: Mon, 18 Feb 2008 07:47:09 +0100

----------=_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--

From: "abi raps" <[email-masked]>
To: [email-masked]
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

----------=_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--

From: "jure Engqvist" <[email-masked]>
To: [email-masked]
Subject: Let her choose between a rock and a hard DlCK...
Date: Sun, 17 Feb 2008 05:27:11 +0100

----------=_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--

From: "addison Forte" <[email-masked]>
To: [email-masked]
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

----------=_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--

From: "Khamsone Piatek" <[email-masked]>
To: [email-masked]
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

----------=_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--

Date: Fri, 15 Feb 2008 23:48:00 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: [email-masked], [email-masked], [email-masked]
Sender: [email-masked]

Peter,

Steve

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: [email-masked], [email-masked]
Date: Sat, 16 Feb 2008 17:37:11 +1300
Sender: [email-masked]

Peter.

Date: Fri, 15 Feb 2008 19:52:06 -0500
To: [email-masked] (Peter Gutmann)
From: Stephen Kent <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: [email-masked], [email-masked]
Sender: [email-masked]

Steve

From: The IESG <[email-masked]>
To: IETF-Announce <[email-masked]>
Cc: Internet Architecture Board <[email-masked]>, RFC Editor <[email-masked]>, pkix mailing list <[email-masked]>, pkix chair <[email-masked]>
Subject: Protocol Action: 'Internet X.509 Public Key  Infrastructure Certificate and Certificate Revocation List (CRL)  Profile' to Proposed Standard 
Date: Fri, 15 Feb 2008 12:04:41 -0800 (PST)
Sender: [email-masked]

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.

From: [email-masked] (Peter Gutmann)
To: [email-masked], [email-masked]
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Cc: [email-masked]
Date: Sat, 16 Feb 2008 02:14:59 +1300
Sender: [email-masked]

Peter.

From: "Marissa Blaney" <[email-masked]>
To: [email-masked]
Subject: Tired of lacking confidence because you have a small c0ck?
Date: Thu, 14 Feb 2008 05:59:00 +0100

----------=_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--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-rfc3280bis-11.txt 
Date: Wed, 13 Feb 2008 16:15:01 -0800 (PST)
Sender: [email-masked]

--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 
[email-masked] 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:
	[email-masked].
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="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

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:	<[email-masked]>

--OtherAccess--

--NextPart--

From: "BULL sharp" <[email-masked]>
To: [email-masked]
Subject: Give the girls MAXIMUM satisfaction
Date: Tue, 12 Feb 2008 21:34:49 -0500

----------=_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--

From: "fabien Asselin" <[email-masked]>
To: [email-masked]
Subject: Give her the best gift this Spring
Date: Tue, 19 Feb 2008 17:20:30 +0100

----------=_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--

From: "Husla kasa" <[email-masked]>
To: [email-masked]
Subject: No longer want to be shy about your item?
Date: Mon, 11 Feb 2008 22:50:33 +0100

----------=_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--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: draft-ietf-pkix-ecc-subpubkeyinfo-02
Date: Mon, 11 Feb 2008 13:29:51 -0500
Organization: IECA, Inc.
Sender: [email-masked]

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 

>(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?

From: "Kelley Henry" <[email-masked]>
To: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: GetRolex only for 220$.
Date: Mon, 11 Feb 2008 15:21:18 -0100

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

From: "PayPal Center" <[email-masked]>
Subject: Security Measures
Date: Mon, 11 Feb 2008 13:08:10 +0100
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>

From: "Bianca STOLLAR" <[email-masked]>
To: [email-masked]
Subject: Your enlarged package will satisfy her to no end.
Date: Mon, 11 Feb 2008 02:31:23 -0000

----------=_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--

Content-class: urn:content-classes:message
Subject: Re: Q: re: subjectAlternativeName URI encoding.
Date: Sun, 10 Feb 2008 09:56:09 -0800
From: "Hallam-Baker, Phillip" <[email-masked]>
To: "Russ Housley" <[email-masked]>, "Timothy J Miller" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]

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:[email-masked]]
Sent:	Saturday, February 09, 2008 02:25 PM Pacific Standard Time
To:	Timothy J Miller; [email-masked]
Cc:	[email-masked]
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:[email-masked]">mailto:[email-masked]</A>]<BR>=

Sent:&nbsp;&nbsp; Saturday, February 09, 2008 02:25 PM Pacific Standard =
Time<BR>
To:&nbsp;&nbsp;&nbsp;&nbsp; Timothy J Miller; [email-masked]<BR>
Cc:&nbsp;&nbsp;&nbsp;&nbsp; [email-masked]<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--

From: "Carmina Hurley" <[email-masked]>
To: [email-masked]
Subject: Let her ride your c0ck to ecstasy
Date: Sun, 10 Feb 2008 11:52:45 -0600

----------=_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--

From: "Rolland Burris" <[email-masked]>
To: "Virginia Ratliff" <[email-masked]>
Subject: don.t wait, change your life today!
Date: Sun, 10 Feb 2008 11:03:36 +0100

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

From: "katarina Holtsclaw" <[email-masked]>
To: [email-masked]
Subject: Unlease that watering hose inside your pants
Date: Sun, 10 Feb 2008 09:24:34 +0100

----------=_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--

From: "davor Bednar" <[email-masked]>
To: [email-masked]
Subject: Being normal is not good enough, you need a bigger d1ck
Date: Sat, 9 Feb 2008 23:45:43 +0100

----------=_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--

Date: Sat, 09 Feb 2008 15:17:57 -0500
To: Timothy J Miller <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: Q: re: subjectAlternativeName URI encoding.
Cc: [email-masked]
Sender: [email-masked]

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
>

From: "Van Briggs" <[email-masked]>
To: "Freddy Parsons" <[email-masked]>
Subject: You won't spend to much for these gifts!
Date: Sun, 10 Feb 2008 03:37:27 -1600

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

From: diplomatic <[email-masked]>
To: [email-masked]
Subject: no degree
Date: Sat, 9 Feb 2008 16:14:06 +0100

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

From: "sardescu Simonson" <[email-masked]>
To: [email-masked]
Subject: It has never been this easy to change your life as radically as now
Date: Sat, 9 Feb 2008 15:16:10 +0100

----------=_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--

From: "Janko Prottsman" <[email-masked]>
To: [email-masked]
Subject: Life will never be the same again with your new huge dck
Date: Sat, 9 Feb 2008 10:53:38 +0400

----------=_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--

To: [email-masked]
From: Timothy J Miller <[email-masked]>
Subject: Q: re: subjectAlternativeName URI encoding.
Date: Fri, 8 Feb 2008 12:52:41 -0600
Sender: [email-masked]

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

--Apple-Mail-2-851265407--

To: [email-masked]
From: Timothy J Miller <[email-masked]>
Subject: 
Date: Fri, 8 Feb 2008 12:38:38 -0600
Sender: [email-masked]

auth 6f743221032bf173612a374a4b723078 subscribe ietf-pkix Timothy J  
Miller <[email-masked]>

From: "Shephali LeBaugh" <[email-masked]>
To: [email-masked]
Subject: It has never been this easy to change your life as radically as now
Date: Fri, 8 Feb 2008 17:23:40 +0100

----------=_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--

From: "Weldon Blevins" <[email-masked]>
To: <[email-masked]>
Subject: dodd
Date: Thu, 7 Feb 2008 17:04:20 +0500

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

From: "Janna Self" <[email-masked]>
To: [email-masked]
Subject: Incredible Irresistable Insatiable ROCK HARD ALL DAY LONG
Date: Thu, 7 Feb 2008 21:13:12 +0100

----------=_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--

Date: Thu, 7 Feb 2008 11:22:40 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Sender: [email-masked]

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

From: "blackburn Eirschele" <[email-masked]>
To: [email-masked]
Subject: Your most magnificent toy ever, unleashed amongst women with a vengeance.
Date: Thu, 7 Feb 2008 02:34:40 +0100

----------=_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--

Date: Wed, 6 Feb 2008 08:21:15 -0800
To: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: encoding rules for explicitText (was Re: draft-ietf-pkix-rfc3280bis-11.txt)
Sender: [email-masked]

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

Date: Wed, 6 Feb 2008 07:38:31 -0800
To: Jean-Marc Desperrier <[email-masked]>, pkix <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.txt
Sender: [email-masked]

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

From: "Daag Arneson" <[email-masked]>
To: [email-masked]
Subject: Your most magnificent toy ever, unleashed amongst women with a vengeance.
Date: Wed, 6 Feb 2008 15:05:16 +0100

----------=_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--

Date: Wed, 06 Feb 2008 09:01:21 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: encoding rules for explicitText (was Re: draft-ietf-pkix-rfc3280bis-11.txt)
Sender: [email-masked]

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

Date: Wed, 06 Feb 2008 11:35:48 +0100
From: Peter Sylvester <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.txt
Sender: [email-masked]

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

--------------ms020708050407060102070005--

Date: Wed, 06 Feb 2008 09:53:06 +0100
From: Jean-Marc Desperrier <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.txt
Sender: [email-masked]

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)

Date: Tue, 5 Feb 2008 14:51:38 -0800
To: "David A. Cooper" <[email-masked]>, pkix <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: draft-ietf-pkix-rfc3280bis-11.txt
Sender: [email-masked]

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

From: "Kaleena ganton" <[email-masked]>
To: [email-masked]
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

----------=_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--

Date: Tue, 05 Feb 2008 14:19:29 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: draft-ietf-pkix-rfc3280bis-11.txt
Sender: [email-masked]

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

From: "Alle bagdasaryan" <[email-masked]>
To: [email-masked]
Subject: She gives me head EVERY night now that I have such a large pecker
Date: Tue, 5 Feb 2008 17:22:31 +0100

----------=_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--

From: "Jina Nery" <[email-masked]>
To: [email-masked]
Subject: Chicks love a huge dick, get one too.
Date: Tue, 5 Feb 2008 05:51:56 +0100

----------=_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--

From: "Sasha V. Koenig" <[email-masked]>
To: "Juliana A. Ogden" <[email-masked]>
Subject: Our experts recommend
Date: Mon, 04 Feb 2008 09:36:35 +0400

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

From: "Xiaoning Berdan" <[email-masked]>
To: [email-masked]
Subject: Make Valentine's Day Night a memorable one.
Date: Sat, 2 Feb 2008 06:54:53 +0200

----------=_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--

From: "Xuong Gyno" <[email-masked]>
To: [email-masked]
Subject: Get a larger C0ck5 with this!
Date: Sun, 3 Feb 2008 14:48:23 +0100

----------=_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--

Date: Sat, 2 Feb 2008 20:24:36 +0600
From: "Doctor Stefanie Hyde" <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Something interesting for you

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!

From: "anecito, Voegtle" <[email-masked]>
To: [email-masked]
Subject: Special prices, 2008 offer
Date: Sat, 2 Feb 2008 22:53:17 -0000

----------=_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--

Date: Sat, 02 Feb 2008 11:52:04 -0500
To: [email-masked]
From: Russ Housley <[email-masked]>
Subject: Fwd: draft-ietf-pkix-ecc-subpubkeyinfo-02
Sender: [email-masked]

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

>From: Alfred =?hp-roman8?B?SM5uZXM=?= <[email-masked]>
>Subject: draft-ietf-pkix-ecc-subpubkeyinfo-02
>To: [email-masked], [email-masked], [email-masked],
>         [email-masked], [email-masked]
>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: (+49)7156/9635-0, Fax: -18         |
>| D-71254  Ditzingen     |  E-Mail:  [email-masked]                     |
>+------------------------+--------------------------------------------+

From: "Kenji Dulude" <[email-masked]>
To: [email-masked]
Subject: 20% gains in girth expected
Date: Sat, 2 Feb 2008 15:07:39 +0100

----------=_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--

From: "Vic Malacarne" <[email-masked]>
To: [email-masked]
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

----------=_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--

Date: Fri, 1 Feb 2008 12:12:37 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Cc: "Stephen Kent" <[email-masked]>, "Stefan Santesson" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Sender: [email-masked]

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

From: "Ilpo mohammed" <[email-masked]>
To: [email-masked]
Subject: Don't wait, add inches today
Date: Fri, 29 Feb 2008 19:17:31 +0100

----------=_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--

From: "Braden creighton" <[email-masked]>
To: [email-masked]
Subject: Intimate bedroom secrets here!
Date: Fri, 29 Feb 2008 13:15:58 +0100

----------=_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--

From: adam <[email-masked]>
To: [email-masked]
Subject: On be trivial
Date: Fri, 29 Feb 2008 15:02:13 +0500

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

From: "Delmar Brennan" <[email-masked]>
To: <[email-masked]>
Subject: Sw|ss R0lex made by top designers
Date: Thu, 28 Feb 2008 21:55:43 +0600

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

From: "Yihua iron" <[email-masked]>
To: [email-masked]
Subject: Intimate bedroom secrets here!
Date: Thu, 28 Feb 2008 20:06:55 +0100

----------=_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--

From: "efioejf mummert" <[email-masked]>
To: [email-masked]
Subject: Love is possible now.
Date: Thu, 28 Feb 2008 05:12:16 -0600

----------=_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--

From: "Eugene Scott" <[email-masked]>
To: "Jesus Green" <[email-masked]>
Subject: The 10 Best Things to Tell a Naked Woman
Date: Wed, 27 Feb 2008 17:21:30 +0800

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

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: Eric Norman <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Date: Wed, 27 Feb 2008 02:20:44 +0100
Cc: [email-masked]
Sender: [email-masked]

Hi,

> 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

Yes, that´s still the case.

Best regards,
Philipp Gühring

From: "DaeHee Sacks" <[email-masked]>
To: [email-masked]
Subject: Achieve blessed happiness tonight and every night.
Date: Tue, 26 Feb 2008 17:06:01 +0200

----------=_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--

From: "Florea Myumyun" <[email-masked]>
To: [email-masked]
Subject: Achieve blessed happiness tonight and every night.
Date: Tue, 26 Feb 2008 12:58:01 +0100

----------=_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--

Date: Mon, 25 Feb 2008 16:59:04 -0500
To: "Denis Pinkas" <[email-masked]>, [email-masked]
From: Russ Housley <[email-masked]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
Sender: [email-masked]

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

From: "Edna asdas" <[email-masked]>
To: [email-masked]
Subject: Free the inner potential in you.
Date: Mon, 25 Feb 2008 19:43:29 +0100

----------=_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--

Date: Mon, 25 Feb 2008 16:37:32 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Sender: [email-masked]

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

Date: Mon, 25 Feb 2008 16:36:01 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re:  I-D Action:draft-ietf-pkix-ta-mgmt-problem-statement-01.txt
Sender: [email-masked]

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 
>>[email-masked] 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:
>>	[email-masked].
>>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:     <[email-masked]>
>>
>>ENCODING mime
>>FILE /internet-drafts/draft-ietf-pkix-ta-mgmt-problem-statement-01.txt

Date: Mon, 25 Feb 2008 15:49:25 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
Sender: [email-masked]

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_=====--

Date: Fri, 22 Feb 2008 17:37:34 -0500
To: Timothy J Miller <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
Cc: [email-masked]
Sender: [email-masked]

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

From: "Manjeet bergevin" <[email-masked]>
To: [email-masked]
Subject: A huge, thick manhood is an amazing turn on for any girl.
Date: Sat, 23 Feb 2008 15:25:40 -0500

----------=_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--

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>
CC: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 23 Feb 2008 14:25:09 +0000
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 22 februari 2008 21:24
> To: Stefan Santesson
> Cc: Paul Hoffman; [email-masked]; [email-masked]
> 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
> > > [email-masked]] On Behalf Of Paul Hoffman
> > > Sent: den 31 januari 2008 19:28
> > > To: [email-masked]; [email-masked]
> > > 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

From: "Odis Mayer" <[email-masked]>
To: "Damion Alford" <[email-masked]>
Subject: Huge store of cheap and effective health products
Date: Sat, 23 Feb 2008 19:31:09 +0530

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

From: "Alisa Abraham" <[email-masked]>
To: "Lily Hoyt" <[email-masked]>
Subject: Gain your so desired well-being
Date: Sat, 23 Feb 2008 14:15:07 +0100

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

From: "Mellissa agman" <[email-masked]>
To: [email-masked]
Subject: You won't believe the amount you can grow.
Date: Sat, 23 Feb 2008 02:28:04 +0100

----------=_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--

Date: Fri, 22 Feb 2008 17:33:19 -0600
From: Eric Norman <[email-masked]>
Subject: Re: RE: Wildcard DNS. Re: rfc 3280bis
To: [email-masked]
Sender: [email-masked]

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

Eric Norman

Date: Fri, 22 Feb 2008 15:23:48 -0500
To: Stefan Santesson <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Cc: Paul Hoffman <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

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
> > [email-masked]] On Behalf Of Paul Hoffman
> > Sent: den 31 januari 2008 19:28
> > To: [email-masked]; [email-masked]
> > 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

Date: Fri, 22 Feb 2008 14:23:34 -0500
To: "David A. Cooper" <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: pkix <[email-masked]>
Sender: [email-masked]

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
>

Content-class: urn:content-classes:message
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Date: Fri, 22 Feb 2008 12:01:53 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Dave

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

Hi Philipp,

Stefan Santesson
Senior Program Manager

Cc: [email-masked]
From: Timothy J Miller <[email-masked]>
Subject: Re: observations on the Clearance and CA Clearance extension discussion
Date: Fri, 22 Feb 2008 10:34:30 -0600
To: Stephen Kent <[email-masked]>
Sender: [email-masked]

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

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

Date: Fri, 22 Feb 2008 07:57:35 -0800
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Sender: [email-masked]

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

From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 22 Feb 2008 15:50:07 +0000
Subject: RE: WG Review: Recharter of Public-Key Infrastructure (X.509) (pkix)
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Paul, If the Security ADs are willing to swallow such text, I would love to include it.

Stefan Santesson
Senior Program Manager

> [email-masked]] On Behalf Of Paul Hoffman
> Sent: den 31 januari 2008 19:28
> To: [email-masked]; [email-masked]
> 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

Date: Fri, 22 Feb 2008 16:48:14 +0100
From: "Denis Pinkas" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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
>> [email-masked]] On Behalf Of Russ Housley
>> Sent: den 12 januari 2008 15:18
>> To: [email-masked]
>> 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

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Fri, 22 Feb 2008 09:58:57 -0500
From: "Carl Wallace" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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.

From: Stefan Santesson <[email-masked]>
To: Carl Wallace <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 22 Feb 2008 14:56:12 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

[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

> [email-masked]] On Behalf Of Carl Wallace
> Sent: den 21 februari 2008 19:27
> To: [email-masked]
> 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.

From: "rosario Hollywood" <[email-masked]>
To: [email-masked]
Subject: Be the Hot Stud at every party.
Date: Fri, 22 Feb 2008 07:15:49 -0500

----------=_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--

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Fri, 22 Feb 2008 07:09:10 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Timothy J Miller" <[email-masked]>
Cc: "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, February 21, 2008 6:45 PM
To: Timothy J Miller; Santosh Chokhani
Cc: Russ Housley; [email-masked]
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

> From: Timothy J Miller [mailto:[email-masked]]
> Sent: den 21 februari 2008 21:12
> To: Santosh Chokhani
> Cc: Stefan Santesson; Russ Housley; [email-masked]
> 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

From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 22 Feb 2008 08:56:08 +0000
Subject: RE: observations on the Clearance and CA Clearance extension discussion
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Stephen Kent
Sent: den 21 februari 2008 19:37
To: [email-masked]
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"'> [email-masked]
[mailto:[email-masked]] <b>On Behalf Of </b>Stephen Kent<br>
<b>Sent:</b> den 21 februari 2008 19:37<br>
<b>To:</b> [email-masked]<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_--

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, Timothy J Miller <[email-masked]>
CC: "[email-masked]" <[email-masked]>
Date: Fri, 22 Feb 2008 08:14:54 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

From: Stefan Santesson <[email-masked]>
To: =?iso-8859-1?Q?Philipp_G=FChring?= <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 22 Feb 2008 07:41:46 +0000
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Hi Philipp,

Stefan Santesson
Senior Program Manager

> certificates to handle wildcards with TLS servers? )

From: "Janne Jonker" <[email-masked]>
To: [email-masked]
Subject: Growth and girth is GUARANTEED.
Date: Fri, 22 Feb 2008 08:22:43 -0800

----------=_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--

Date: Fri, 22 Feb 2008 17:09:15 +1100
From: Stephen Wilson <[email-masked]>
Reply-To: [email-masked]
Organization: Lockstep
To: [email-masked]
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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 +61 (0)414 488 851

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.

Date: Thu, 21 Feb 2008 23:09:28 -0500
To: Timothy J Miller <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: Russ Housley <[email-masked]>, [email-masked]
Sender: [email-masked]

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

From: Philipp =?iso-8859-1?q?G=FChring?= <[email-masked]>
Organization: Futureware 2001
To: "[email-masked]" <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Date: Fri, 22 Feb 2008 00:50:33 +0100
Sender: [email-masked]

Hi,

Yes.

Best regards,
Philipp Gühring

From: Stefan Santesson <[email-masked]>
To: Timothy J Miller <[email-masked]>, Santosh Chokhani <[email-masked]>
CC: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 21 Feb 2008 23:45:28 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

> From: Timothy J Miller [mailto:[email-masked]]
> Sent: den 21 februari 2008 21:12
> To: Santosh Chokhani
> Cc: Stefan Santesson; Russ Housley; [email-masked]
> 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

Date: Thu, 21 Feb 2008 15:14:52 -0800
To: [email-masked]
From: Paul Hoffman <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: Russ Housley <[email-masked]>
Sender: [email-masked]

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

Date: Thu, 21 Feb 2008 13:36:36 -0500
To: [email-masked]
From: Stephen Kent <[email-masked]>
Subject: observations on the Clearance and CA Clearance extension discussion
Sender: [email-masked]

--============_-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============--

Date: Thu, 21 Feb 2008 17:37:51 -0500
From: "David A. Cooper" <[email-masked]>
To: Russ Housley <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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

Cc: "'Santosh Chokhani'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, "'Russ Housley'" <[email-masked]>, <[email-masked]>
From: Timothy J Miller <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 15:13:13 -0600
To: "Turner, Sean P." <[email-masked]>
Sender: [email-masked]

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

--Apple-Mail-8--164589378--

Cc: [email-masked]
From: Timothy J Miller <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 15:07:53 -0600
To: Russ Housley <[email-masked]>
Sender: [email-masked]

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

--Apple-Mail-7--164900811--

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 16:07:47 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Timothy J Miller" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
Sent: Thursday, February 21, 2008 3:12 PM
To: Santosh Chokhani
Cc: Stefan Santesson; Russ Housley; [email-masked]
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"

------=_NextPart_000_00A4_01C874A3.E64B3980--

From: "Turner, Sean P." <[email-masked]>
To: "'Timothy J Miller'" <[email-masked]>, "'Santosh Chokhani'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>, "'Russ Housley'" <[email-masked]>, <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 15:48:02 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Date: Thu, 21 Feb 2008 15:48:30 -0500
To: Timothy J Miller <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Cc: [email-masked]
Sender: [email-masked]

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

From: "Asher hoekstra" <[email-masked]>
To: [email-masked]
Subject: Tired of the stares you get for your tiny pecker? Click here now.
Date: Thu, 21 Feb 2008 21:26:20 +0100

----------=_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--

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-pkix-ecc-subpubkeyinfo-03.txt 
Date: Thu, 21 Feb 2008 12:15:01 -0800 (PST)
Sender: [email-masked]

--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 
[email-masked] 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--

Cc: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>
From: Timothy J Miller <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 14:12:40 -0600
To: Stefan Santesson <[email-masked]>
Sender: [email-masked]

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

--Apple-Mail-2--168221769--

Cc: "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
From: Timothy J Miller <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 14:11:49 -0600
To: "Santosh Chokhani" <[email-masked]>
Sender: [email-masked]

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

--Apple-Mail-1--168263324--

Date: Thu, 21 Feb 2008 15:05:51 -0500
From: "David A. Cooper" <[email-masked]>
To: pkix <[email-masked]>
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Sender: [email-masked]

Stefan,

Dave

Date: Thu, 21 Feb 2008 18:34:26 +0000
From: Stephen Farrell <[email-masked]>
To: "Kemp, David P." <[email-masked]>
CC: [email-masked]
Subject: Re: Wildcard DNS. Re: rfc 3280bis
Sender: [email-masked]

Stephen.

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 13:26:35 -0500
From: "Carl Wallace" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Date: Thu, 21 Feb 2008 13:03:42 -0500
From: "Kemp, David P." <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Dave

-----Original Message-----

Stefan Santesson
Senior Program Manager

the
> should submit an April 1st RFC on the topic.

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 12:16:39 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Russ Housley" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Thursday, February 21, 2008 11:07 AM
To: Russ Housley; [email-masked]
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

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 12 januari 2008 15:18
> To: [email-masked]
> 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

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 11:53:26 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: "Carl Wallace" <[email-masked]>, "pkix" <[email-masked]>
Sender: [email-masked]

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:[email-masked]] 
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.
>
> 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.
>>     
>
>
>   

Date: Thu, 21 Feb 2008 11:48:41 -0500
From: "David A. Cooper" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: Carl Wallace <[email-masked]>, pkix <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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

Date: Thu, 21 Feb 2008 11:34:40 -0500
From: "David A. Cooper" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: [email-masked]
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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
>   

From: Stefan Santesson <[email-masked]>
To: Stephen Kent <[email-masked]>, Peter Gutmann <[email-masked]>
CC: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 21 Feb 2008 16:33:26 +0000
Subject: RE: Wildcard DNS. Re: rfc 3280bis
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Stefan Santesson
Senior Program Manager

> should submit an April 1st RFC on the topic.

From: "Turner, Sean P." <[email-masked]>
To: "'David A. Cooper'" <[email-masked]>
Cc: "'pkix'" <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 11:18:27 -0500
Organization: IECA, Inc.
Sender: [email-masked]

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

>From: David A. Cooper [mailto:[email-masked]] 
>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
>

From: Stefan Santesson <[email-masked]>
To: Russ Housley <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 21 Feb 2008 16:07:11 +0000
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

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

> [email-masked]] On Behalf Of Russ Housley
> Sent: den 12 januari 2008 15:18
> To: [email-masked]
> 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

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 11:07:08 -0500
From: "Santosh Chokhani" <[email-masked]>
To: "David A. Cooper" <[email-masked]>, "Carl Wallace" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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: [email-masked] [mailto:[email-masked]]
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.

Date: Thu, 21 Feb 2008 10:57:40 -0500
From: "David A. Cooper" <[email-masked]>
To: "Turner, Sean P." <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 10:41:53 -0500
From: "Carl Wallace" <[email-masked]>
To: "David A. Cooper" <[email-masked]>
Cc: "pkix" <[email-masked]>
Sender: [email-masked]

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.

Date: Thu, 21 Feb 2008 10:31:54 -0500
From: "David A. Cooper" <[email-masked]>
To: Carl Wallace <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: Clearance & CA Clearance Constraints Cert Ext ID
Sender: [email-masked]

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.

Content-class: urn:content-classes:message
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Thu, 21 Feb 2008 08:28:14 -0500
From: "Carl Wallace" <[email-masked]>
To: "pkix" <[email-masked]>
Sender: [email-masked]

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

From: "Maritsa Bornzin" <[email-masked]>
To: [email-masked]
Subject: Great bedroom stories start with this.
Date: Thu, 21 Feb 2008 13:28:14 +0200

----------=_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--

From: "Turner, Sean P." <[email-masked]>
To: <[email-masked]>
Subject: RE: Clearance & CA Clearance Constraints Cert Ext ID
Date: Wed, 20 Feb 2008 20:47:14 -0500
Organization: IECA, Inc.
Sender: [email-masked]

Dave,

Comments in line...

spt

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