Subject: Embedded certificate image

From: Stefan Santesson <[email-masked]>
Date: Mon, 20 Jul 2009 19:49:36 +0200

This is the first of two unresolved issues listed in the Certimage draft.

Is there any reason to provide any means to embed certificate images in a
certificate.

The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory
capacity to allow certificate images to be stored in the certificate itself.
By storing the image in the certificate, we could save a network retrieval.

The main counter argument is that it would be a serious disadvantage if a
certificate occasionally needs to be used in a constrained environment and
the fact that the base standard that we are updating (RFC 3709) simply does
not allow embedded images.

One way to do this could be to store images in a separate extension and then
define  a way to reference that image from the logotype extension through an
internal reference.

My proposed resolution is to exclude local storage from the current draft.
Defining local embedding is adding unnecessary complexity to the draft.

If a strong reason emerges to allow local storage, then this can be defined
in a separate draft.

/Stefan

---

From: "Thomas Hardjono" <[email-masked]>
Date: Mon, 20 Jul 2009 16:44:04 -0400

Stefan,
 
Has there been any thought about making such an extension "generic" enough
that it could reference other human-friendly objects (e.g. InfoCard, OpenID
identity, etc. etc).
 
/thomas/

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Stefan Santesson
Sent: Monday, July 20, 2009 1:50 PM
To: ietf-pkix
Subject: Embedded certificate image

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 20 Jul 2009 23:43:10 +0200

Hi Thomas,

When discussing the particular issue at hand, it has just been considered in
relation to certificate images.
However I agree that if we would create such extension, that we should make
it generic.

I think that is yet another good argument that such extension should be
separated from the certimage work.

What is your assessment on the actual need to store objects like an
information card inside a certificate?

/Stefan

On 09-07-20 10:44 PM, "Thomas Hardjono" <[email-masked]> wrote:

> Stefan,
>  
> Has there been any thought about making such an extension ³generic² enough
> certificate occasionally needs to be used in a constrained environment and the
> fact that the base standard that we are updating (RFC 3709) simply does not
> allow embedded images.
> 
> If a strong reason emerges to allow local storage, then this can be defined in
> a separate draft.
> 
> /Stefan 
>

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 21 Jul 2009 08:33:29 +0200

In the "competing" proposal, certificate images are locally stored
but not embedded in certificates.  This is a viable solution when
images are only to be consumed by the end-user.  For external
consumption (which I consider an entirely different use-case),
the existing I-D seems quite sufficient.

Anders

Stefan Santesson wrote:
> Is there any reason to provide any means to embed certificate images 
> in a certificate.
>
> capacity to allow certificate images to be stored in the certificate 
> itself. By storing the image in the certificate, we could save a 
> network retrieval.
>
> The main counter argument is that it would be a serious disadvantage 
> if a certificate occasionally needs to be used in a constrained 
> environment and the fact that the base standard that we are updating 
> (RFC 3709) simply does not allow embedded images.
>
> One way to do this could be to store images in a separate extension 
> and then define  a way to reference that image from the logotype 
> extension through an internal reference.
>
> If a strong reason emerges to allow local storage, then this can be 
> defined in a separate draft.
>
> /Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 21 Jul 2009 08:54:05 +0200

Anders,

I'm not sure what you mean by "competing" proposal, but a reasonable
behavior by the client is to cache the certificate image once it has
obtained it, creating the situation where the image is locally stored but
not embedded.

But you won't get away from that first retrieval.

/Stefan

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 21 Jul 2009 11:10:44 +0200

Stefan,

 >I'm not sure what you mean by "competing" proposal

If you look back a few months on my comments to the cert-image I-D
you'll find pointers to an entirely different proposal which is built
on top of a new provisioning protocol which in turn builds on a
revised TPM-based key storage scheme:
http://webpki.org/papers/keygen2/secure-key-store.pdf

The "humble" goal is unifying Information Cards, PKI, and OTP because
they are all useful but support quite distinct use-cases.

Isn't this incredibly difficult to succeed with?  Probably, but there is
no competition at least, since most people appear awfully busy solving
yesterdays' problems (like PKI middleware), ignoring higher-level aspects
of tokens such as utility in the real world where you need to deal with
multiple identities and technologies.

In addition, "iPhone & friends" have shown that the Mobile Internet
finally is here while interoperable and generally available authentication
solutions are not.   The described solution is also designed to fill 
this vacuum.

Anders

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 21 Jul 2009 11:57:41 +0200

I¹m sorry Anders, but totally fail to see how this has anything to do with
the discussed issue.

I don¹t see any ³competing proposal²
Is there any chance you could give me a distinct short explanation in one
sentence or two that would help me understand.

/Stefan

On 09-07-21 11:10 AM, "Anders Rundgren" <[email-masked]> wrote:

> solutions are not.   The described solution is also designed to fill this
> vacuum.
> 
> Anders
> 
> Stefan Santesson wrote:
>>  
>> Anders,
>> 
>> On 09-07-21 8:33 AM, "Anders Rundgren" <[email-masked]>
>> <mailto:[email-masked]>  wrote:
>> 
>>   
>>  
>>>

---

From: "Thomas Hardjono" <[email-masked]>
Date: Tue, 21 Jul 2009 16:13:33 -0400

Hi Stefan,
 
In my (limited) view of looking at where the world of identity & ID
federation is heading, it seems that X509 certs could have a major role
(depending on how it is architected). The problem is that the complexity of
X509 (perceived and real) have really put-off people in the identity space
from considering it for direct use as an identity structure.
 
So for X509 to play a role in the new identity "layer" on the Internet, it
really should remain technology-under-the-hood that the average users should
never see.  In fact, I think the PKIX community should right now be thinking
about (a) how X509 can complement (not replace or supplant) other emerging
identity structures, and (b) how a PKI-infrastructure could support the
identity metasystem infrastructure that organizations are rolling-out.
 
To the end of making an X.509 more human-friendly and more "identity
friendly", embedding an image inside a cert could be a very attractive way
to bridge the two worlds. Given the large amounts of traffic being exchanged
among identity metasystem infrastructure entities (think SAML stuff, and
WS-S stuff over SOAP), I don't the size of an X509+image cert matters any
more at the identity layer.
 
/thomas/

From: Stefan Santesson [mailto:[email-masked]] 
Sent: Monday, July 20, 2009 5:43 PM
To: Thomas Hardjono; 'ietf-pkix'
Subject: Re: Embedded certificate image
 
Hi Thomas,

/Stefan

 
/thomas/

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 21 Jul 2009 23:16:50 +0200

Anders,

Thanks for the clarifications provided off-line.
I just wanted to recap here on the list.

As we have concluded there are some variants for storing a locally selected
image with the certificate for local use. That is, in a way that does
benefit the certificate holder but not the relying party.
Information Card is one such technology and the system you are working on is
another.

As I think we concluded, these represent other use cases than the one the
certimage draft is addressing and IMO they are more complementary than
competing in the sense that if the issuer has provided an image, then it
will be a good candidate image for local use.

Nothing in this suggest that the certimage draft should provide a solution
for local storage of the image data.

/Stefan

On 09-07-21 11:57 AM, "Stefan Santesson" <[email-masked]> wrote:

> I¹m sorry Anders, but totally fail to see how this has anything to do with the
> discussed issue.
>

---

From: Stefan Santesson <[email-masked]>
Date: Tue, 21 Jul 2009 23:37:58 +0200

Thomas,

We do indeed see a wave of identity federation in many areas. In many
aspects this is very healthy. We have seen huge success in the academic
world. We can further see that the European Union is betting heavily on
identity federation to solve cross border identity recognition. However, in
other aspects we are getting extremely close to truth #6 of networking (RFC
1925). It is is easier to move a problem around than it is to solve it.
(Thanks Peter Gutman for reminding me of this truth).

One aspect that is almost forgotten currently in the hype is that we need
solutions for electronic signatures and encryption and identification of
services to users, not just single sign on. Identity federation will not
solve all these cases and we may end up with parallel solutions for
different use cases. We might want to hide the technology for the users, but
we have also hidden the important result of the technology... To display the
certified identity of the identified opponent.

I do agree on your conclusion, but I have more seen the cert image as a good
candidate image for an information card, but never the need to store an
information card in a certificate.

/Stefan

On 09-07-21 10:13 PM, "Thomas Hardjono" <[email-masked]> wrote:

> Hi Stefan,
>  
> In my (limited) view of looking at where the world of identity & ID federation
> is heading, it seems that X509 certs could have a major role (depending on how
> it is architected). The problem is that the complexity of X509 (perceived and
> real) have really put-off people in the identity space from considering it for
> direct use as an identity structure.
>  
> So for X509 to play a role in the new identity ³layer² on the Internet, it
> To the end of making an X.509 more human-friendly and more ³identity
> friendly², embedding an image inside a cert could be a very attractive way to
> bridge the two worlds. Given the large amounts of traffic being exchanged
> among identity metasystem infrastructure entities (think SAML stuff, and WS-S
> stuff over SOAP), I don¹t the size of an X509+image cert matters any more at
> the identity layer.
>  
> /thomas/
>  
>  
>  
> 
> However I agree that if we would create such extension, that we should make it
> generic.
>

---

From: Stefan Santesson <[email-masked]>
Date: Wed, 29 Jul 2009 23:55:37 +0200

Jim Schaad provided a very interesting idea to this issue at PKIX today

It seems that there are ways to store base64 encoded data in a URL. Since
all images are located through a URL, this opens interesting possibilities
if the URL actually contains the image data itself.

I think it could make sense in many situations and environments to provide
the image inside the certificate in this form.

Russ came up with a concern that all hash attacks loves big chunks of random
data that can be used to create collisions. Counter arguments is that this
is only a concern is a week hash is used and also that the data has some
structure as it is base64 encoded.

Jim, could you provide more specific information about the underlying
specification that would enable this?

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Jul 2009 16:10:22 +1200

Stefan Santesson <[email-masked]> writes:

>It seems that there are ways to store base64 encoded data in a URL. Since all
>images are located through a URL, this opens interesting possibilities if the
>URL actually contains the image data itself.

How big are these things going to get?  Anything beyond about 1024 characters
and you start running into problems with things that reject over-long URLs.

Peter.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 30 Jul 2009 07:26:53 +0300

I guess that if the image is embedded in the URL, you don't really need to follow it, just process it locally.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Gutmann
Sent: Thursday, July 30, 2009 7:10 AM
To: [email-masked]; [email-masked]
Subject: Re: Embedded certificate image

Peter.

Email secured by Check Point

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Jul 2009 08:26:52 +0200

Exactly

On 09-07-30 6:26 AM, "Yoav Nir" <[email-masked]> wrote:

> Behalf Of Peter Gutmann

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Jul 2009 19:36:30 +1200

>follow it, just process it locally.

In that case why encode it as a URL in the first place?

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Jul 2009 09:44:30 +0200

Good question.

The reason would be to allow data to be stored locally when the original
specification only offers the option to specify a URL to the location of the
data.

This is the case for RFC 3709, which is the standard we would use to bind a
cert image to the certificate. RFC 3709 does only offer a URL as means of
referring to the actual image, it does not offer any other means of local
storage.

By providing the image in the URL, we could offer a way to embed the image
and still stay within the syntax of the original spec.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Jul 2009 10:14:39 +0200

Peter,

In-line;

On 09-07-30 10:01 AM, "Peter Gutmann" <[email-masked]> wrote:

> Why not use one of the type-and-value options, OtherLogoTypeInfo or something?
> This just seems like a horrible kludge, like pounding a nail with a scredriver
> because that's what was lying around.

We have concluded that the RFC 3709 syntax does not allow any such option or
extensibility. It's either in the URL or nothing at all.

> 
> How do you distinguish real URLs from not-a-real-URLs?
> 
> Peter.
> 

That is my question to Jim. Apparently there is an RFC that would tell.

In any case, this is just an interesting idea that we should investigate. I
have scary feelings too about this but I would like to turn the stone and
look at it before throwing this option away.

/Stefan

---

From: Peter Gutmann <[email-masked]>
Date: Thu, 30 Jul 2009 20:01:23 +1200

Peter.

---

From: "Jim Schaad" <[email-masked]>
Date: Thu, 30 Jul 2009 12:56:10 +0200

RFC 2397  The data URL scheme.  Limitations on the length of the URL are
application dependent.

> From: [email-masked] [mailto:owner-ietf-
> [email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, July 30, 2009 10:15 AM
> To: Peter Gutmann; [email-masked]; [email-masked]

---

From: "Miller, Timothy J." <[email-masked]>
Date: Thu, 30 Jul 2009 10:16:43 -0400

>Russ came up with a concern that all hash attacks loves big chunks of
>random data that can be used to create collisions. Counter arguments is
>that this is only a concern is a week hash is used and also that the
>data has some structure as it is base64 encoded.

Since no-one knows what the next weakness in any hash will be, this isn't a
valid counter-argument to Russ's point, IMHO.  SHA1 could be completely
broken tomorrow.

Sotirov, Stevens, Lenstra, et.al. would have had an easier time, I should
think, if there was a big chunk of data in each cert *other* than they key.
Also, the actual image data is largely unstructrured past the image header;
but any structure in this data is largely immaterial to a collision
construction attack.

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Jul 2009 16:43:36 +0200

Understood,

However, I can't escape that it feels a bit warped if we abandon useful
features because we must design protocols to resist weak hashes instead of
making sure that we can and do use adequate hash algorithms.

On the second point, the data in both SVG and PDF/A are highly structured.
SVG is for example an XML based vector graphic language.

/Stefan

---

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 30 Jul 2009 10:32:59 -0500

> making sure that we can and do use adequate hash algorithms.

It's a risk-management decision, in the end.  The question is, whose 
risk is it?  The protocol designer's, or the end user's?

> SVG is for example an XML based vector graphic language.

I can bury arbitrary amounts of unstructured data in both SVG and PDF/A. 
  SVG allows the same RFC2397 data URLs that you were discussing 
previously, and you can embed fonts in both PDF/A (it's actually 
required) and SVG.  :)

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Jul 2009 20:31:57 +0200

So, with all things taken into account, what is your opinion on what we
should do?

Do you argue that we should ignore the feature because it may enhance hash
attacks?

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 30 Jul 2009 14:55:55 -0400

I do not mean to intrude, but is this data being provided by the
applicant or is this something structured created by the CA or gotten by
the CA from a source that applicant does not control.

I ask because depending on the answer, this may become pre-image attack
and hence impractical. 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, July 30, 2009 2:32 PM
> To: Timothy J. Miller
> Cc: ietf-pkix
> So, with all things taken into account, what is your opinion 
> on what we should do?
> 
> Do you argue that we should ignore the feature because it may 
> enhance hash attacks?
> 
> /Stefan
> 
> >> However, I can't escape that it feels a bit warped if we abandon 
> >> useful features because we must design protocols to resist weak 
> >> hashes instead of making sure that we can and do use 
> adequate hash algorithms.
> >

---

From: Stefan Santesson <[email-masked]>
Date: Thu, 30 Jul 2009 21:52:39 +0200

This is data generated by the CA.

Some included elements, like logotype of the subject organization may be
provided by the applicant but the certificate image is assembled and created
by the CA.

/Stefan

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 30 Jul 2009 15:55:05 -0400

Then, a security considerations section describing how this field does
not aid in collision attack should be sufficient. 

> Sent: Thursday, July 30, 2009 3:53 PM
> To: Santosh Chokhani; Timothy J. Miller
> Cc: ietf-pkix
> Some included elements, like logotype of the subject 
> organization may be provided by the applicant but the 
> certificate image is assembled and created by the CA.
> 
> /Stefan
> 
> 
> > applicant or is this something structured created by the CA 
> or gotten 
> > by the CA from a source that applicant does not control.
> > 
> > I ask because depending on the answer, this may become pre-image 
> > attack and hence impractical.
> > 
> >> So, with all things taken into account, what is your 
> opinion on what 
> >> we should do?
> >> 
> >> Do you argue that we should ignore the feature because it 
> may enhance 
> >> hash attacks?
> >> 
> >> /Stefan
> >>

---

From: "Moudrick M. Dadashov" <[email-masked]>
Date: Thu, 30 Jul 2009 23:21:36 +0300

Sorry, I didn't get the idea. Do you mean the CA will create those 
logotypes or the logotypes will be presented to CA as any other Subject 
related data to be included in the certificate?

M.D.

Stefan Santesson wrote:
>>>> It's a risk-management decision, in the end.  The question
>>>>         
>>> is, whose 
>>>       
>>>>> On the second point, the data in both SVG and PDF/A are
>>>>>           
>>> highly structured.
>>>       
>>>> I can bury arbitrary amounts of unstructured data in both
>>>>         
>>> SVG and PDF/A.
>>>

---

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 30 Jul 2009 15:33:42 -0500

> I ask because depending on the answer, this may become pre-image attack

I went and refreshed myself on Stevens et.al.'s paper (and Lenstra's 
site on colliding X.509) and while I continue to struggle to understand 
it I think the following is true:

The presence of a large applicant-controlled data block like an image in 
the extensions would allow a chosen prefix attack using the extension to 
house the colliding suffixes (S and S') and the tail construction (T). 
This eliminates the restriction that S||T and S'||T must form a valid 
RSA modulus, and opens the possibility that the attacker can use more 
near-collision blocks (if the image is larger than the key).  This would 
make the attack easier, but I have no earthly idea by how much.

On the other hand, the larger prefixes P and P' (as they now include the 
whole cert up to the extensions) makes it easier for the CA to confound 
the chosen-prefix attack.  The CA would only need to place an 
unpredictable extension *before* the id-pe-logotype prior to signing; 
that's a simple enough reordering step.

It's worth noting that I think this concern applies to RFC3709 too.

So what would I do?  To be safe, you could do one or more of the following:

- Require the CA to reorder the extensions prior to signing, and never 
place id-pe-logotype first.

- Specify that the image data is entirely CA controlled, or contains 
only minimal data that is applicant controlled (and that 
applicant-controlled data in total is less than the key length). 
Ideally, take the applicant data from other fields in the request, 
rather than having the applicant submit his own image data.

- Place an upper limit on refStructURI length.  A length less than the 
key would probably be sufficient.  Whether this would be sufficient to 
house a data URL is an open question; I don't know.

- Finally, prohibiting data URLs entirely is always an option.

The reason I say limit applicant data to less than the key length is 
because that would restrict the number of collision blocks the cert 
image can hold to less than those that can be held in the modulus. This 
increases complexity and time for the attacker if he uses this extension 
for his collision.  He can always use the key unless the CA takes other 
steps to prevent chosen prefix attacks on its own--which, naturally, 
prevents chosen prefix attacks in the extension as well, but requiring 
certain CA behavior for *all* certificates is beyond the scope of this 
document.  Might be worth a paragraph in the security considerations, 
though.

All of this presumes that a chosen-prefix attack against SHA is someday 
possible, of course.  But it's always good to be proactive if it's not 
too difficult.

-- Tim

---

From: "Timothy J. Miller" <[email-masked]>
Date: Thu, 30 Jul 2009 16:02:46 -0500

Santosh Chokhani wrote:

> Stefan is saying that the data is not applicant chosen. 

The subject org logotype in 3709 is applicant chosen and has the same 
problem.

I think the countermeasure of re-ordering extensions is sufficient, and 
is probably worth a security consideration in both specs.

-- Tim

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 30 Jul 2009 16:42:30 -0400

Tim,

> From: Timothy J. Miller [mailto:[email-masked]] 
> Sent: Thursday, July 30, 2009 4:34 PM
> To: Santosh Chokhani
> Cc: Stefan Santesson; ietf-pkix
> I went and refreshed myself on Stevens et.al.'s paper (and 
> Lenstra's site on colliding X.509) and while I continue to 
> struggle to understand it I think the following is true:
> 
> The presence of a large applicant-controlled data block like 
> an image in the extensions would allow a chosen prefix attack 
> using the extension to house the colliding suffixes (S and 
> S') and the tail construction (T). 
> This eliminates the restriction that S||T and S'||T must form 
> a valid RSA modulus, and opens the possibility that the 
> attacker can use more near-collision blocks (if the image is 
> larger than the key).  This would make the attack easier, but 
> I have no earthly idea by how much.
> 
> On the other hand, the larger prefixes P and P' (as they now 
> include the whole cert up to the extensions) makes it easier 
> for the CA to confound the chosen-prefix attack.  The CA 
> would only need to place an unpredictable extension *before* 
> the id-pe-logotype prior to signing; that's a simple enough 
> reordering step.
> 
> - Require the CA to reorder the extensions prior to signing, 
> and never place id-pe-logotype first.
> 
> - Specify that the image data is entirely CA controlled, or 
> contains only minimal data that is applicant controlled (and 
> that applicant-controlled data in total is less than the key length). 
> Ideally, take the applicant data from other fields in the 
> request, rather than having the applicant submit his own image data.
> 
> - Place an upper limit on refStructURI length.  A length less 
> than the key would probably be sufficient.  Whether this 
> would be sufficient to house a data URL is an open question; 
> I don't know.
> 
> The reason I say limit applicant data to less than the key 
> length is because that would restrict the number of collision 
> blocks the cert image can hold to less than those that can be 
> held in the modulus. This increases complexity and time for 
> the attacker if he uses this extension for his collision.  He 
> can always use the key unless the CA takes other steps to 
> prevent chosen prefix attacks on its own--which, naturally, 
> prevents chosen prefix attacks in the extension as well, but 
> requiring certain CA behavior for *all* certificates is 
> beyond the scope of this document.  Might be worth a 
> paragraph in the security considerations, though.
> 
> All of this presumes that a chosen-prefix attack against SHA 
> is someday possible, of course.  But it's always good to be 
> proactive if it's not too difficult.
> 
> -- Tim
>

---

From: "Santosh Chokhani" <[email-masked]>
Date: Thu, 30 Jul 2009 17:37:55 -0400

Tim,

RFC says "The relationship between the subject organization and the
subject
   organization logotype, and the relationship between the issuer and
   either the issuer organization logotype or the community logotype,
   are relationships asserted by the issuer."

It tends to imply that the logotype is predefined data and not in the
certificate request payload.

> Sent: Thursday, July 30, 2009 5:03 PM
> To: Santosh Chokhani
> The subject org logotype in 3709 is applicant chosen and has 
> the same problem.
> 
> I think the countermeasure of re-ordering extensions is 
> sufficient, and is probably worth a security consideration in 
> both specs.
> 
> -- Tim
>

---

From: Tom Gindin <[email-masked]>
Date: Fri, 31 Jul 2009 10:03:29 -0400

But isn't the subject organization's logotype precisely the entity 
which could be manipulated to produce a collision?  What other 
unpredictable data is in the image?  The certificate (as distinct from its 
image) is always assembled and created by the CA, but that didn't stop the 
collision attacks at New Year's.  I tend to agree with Timothy about this 
one.
        The simplest way to make this safe against collisions IMHO is to 
add an optional OCTET STRING as the first item (not the last) in the 
logotype extension and have the CA set it to a random value the same size 
as the digest output whenever it puts in an image.  That should break up 
the prefix attack.  Unfortunatly, there is no corresponding field in the 
base definition.
        I have seen Santosh's citation from 3709, but is the subject 
organization's logotype more a "relationship asserted by the issuer" than 
an OU value?

                Tom Gindin

Stefan Santesson <[email-masked]> 
Sent by: [email-masked]
07/30/2009 03:52 PM

To
Santosh Chokhani <[email-masked]>, "Timothy J. Miller" 
<[email-masked]>
cc
ietf-pkix <[email-masked]>
Subject
Re: Embedded certificate image

Some included elements, like logotype of the subject organization may be
provided by the applicant but the certificate image is assembled and 
created
by the CA.

/Stefan

---

From: "Timothy J. Miller" <[email-masked]>
Date: Fri, 31 Jul 2009 11:57:11 -0500

> certificate request payload.

I'd feel better if it were explicit that the subject logotype is 
provided by the issuer.

As it is, I think it can be read either way.  The issuer asserts 
everything in the cert, after all, but it didn't create it all; much was 
provided by the applicant.

-- Tim

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 31 Jul 2009 20:19:15 +0200

Tim,

It is not reasonable for this standard to dictate what a CA accepts as
input.

/Stefan

---

From: Stefan Santesson <[email-masked]>
Date: Fri, 31 Jul 2009 20:34:25 +0200

The draft we are discussing is the certificate image draft, not the use of
subject logotype with RFC 3709.

A certificate image is composed by the CA even if there may be part of the
image that has been imported, such as a subject logo appearing somewhere
inside the certificate image. The fact that the certificate image is
composed by the CA creates the situation described by Tom. I.e. the imported
image appears somewhere inside the certificate image, therefore it will be
preceded and mixed with data provided by the CA.

/Stefan

---

From: Tom Gindin <[email-masked]>
Date: Fri, 31 Jul 2009 20:07:08 -0400

Stefan:

        While it is unreasonable to dictate what a CA can accept, I think 
that the Security Considerations section should say something like: "the 
information about the certificate subject contained in the image SHOULD 
NOT include any graphic supplied by the applicant".  The "tumor" construct 
which we saw in MD5 collisions could be placed into such a graphic.  Thus 
if a CA were to construct a graphic by inserting a customer-provided 
graphic into a template provided by the CA, it would be subject to the 
same attacks as MD5 certificates have been, but it would not be evident 
from the certificate syntax.

                Tom Gindin

07/31/2009 02:19 PM

To
"Timothy J. Miller" <[email-masked]>, Santosh Chokhani 
<[email-masked]>
cc
ietf-pkix <[email-masked]>
Subject
Re: Embedded certificate image

Tim,

/Stefan

> provided by the applicant.

To: Stefan Santesson <[email-masked]>
Cc: ietf-pkix <[email-masked]>, Santosh Chokhani <[email-masked]>, "Timothy J. Miller" <[email-masked]>
Subject: Re: Embedded certificate image
From: Tom Gindin <[email-masked]>
Date: Fri, 31 Jul 2009 20:07:08 -0400
Sender: [email-masked]

        Stefan:

        While it is unreasonable to dictate what a CA can accept, I think 
that the Security Considerations section should say something like: "the 
information about the certificate subject contained in the image SHOULD 
NOT include any graphic supplied by the applicant".  The "tumor" construct 
which we saw in MD5 collisions could be placed into such a graphic.  Thus 
if a CA were to construct a graphic by inserting a customer-provided 
graphic into a template provided by the CA, it would be subject to the 
same attacks as MD5 certificates have been, but it would not be evident 
from the certificate syntax.

                Tom Gindin

07/31/2009 02:19 PM

To
"Timothy J. Miller" <[email-masked]>, Santosh Chokhani 
<[email-masked]>
cc
ietf-pkix <[email-masked]>
Subject
Re: Embedded certificate image

Tim,

/Stefan

> provided by the applicant.

Date: Fri, 31 Jul 2009 20:34:25 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Tom Gindin <[email-masked]>
CC: ietf-pkix <[email-masked]>, Santosh Chokhani <[email-masked]>, "Timothy J. Miller" <[email-masked]>
Sender: [email-masked]

/Stefan

>>>> previously, and you can embed fonts in both PDF/A (it's actually

Date: Fri, 31 Jul 2009 20:19:15 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>, Santosh Chokhani <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

Tim,

/Stefan

> provided by the applicant.

Date: Fri, 31 Jul 2009 11:57:11 -0500
From: "Timothy J. Miller" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: Stefan Santesson <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

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

-- Tim

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

--------------ms030407070107010104000405--

To: Stefan Santesson <[email-masked]>
Cc: ietf-pkix <[email-masked]>, Santosh Chokhani <[email-masked]>, "Timothy J. Miller" <[email-masked]>
Subject: Re: Embedded certificate image
From: Tom Gindin <[email-masked]>
Date: Fri, 31 Jul 2009 10:03:29 -0400
Sender: [email-masked]

                Tom Gindin

To

/Stefan

>>> previously, and you can embed fonts in both PDF/A (it's actually

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Reply-to: [email-masked]
CC: <[email-masked]>
Subject: Last Call: draft-ietf-pkix-authorityclearanceconstraints (Clearance Attribute and Authority Clearance Constraints Certificate Extension) to Proposed Standard
Date: Fri, 31 Jul 2009 04:50:34 -0700 (PDT)
Sender: [email-masked]

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

- 'Clearance Attribute and Authority Clearance Constraints Certificate 
   Extension '
   <draft-ietf-pkix-authorityclearanceconstraints-02.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-08-14. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

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

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17987&rfc_flag=0

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-ocspagility-01.txt 
Date: Fri, 31 Jul 2009 01:00:01 -0700 (PDT)
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           : OCSP Algorithm Agility
	Author(s)       : P. Hallam-Baker, S. Santesson
	Filename        : draft-ietf-pkix-ocspagility-01.txt
	Pages           : 8
	Date            : 2009-07-31

The OSCP specification defined in RFC 2560 requires server responses
to be signed but does not specify a mechanism for selecting the
signature algorithm to be used leading to possible interoperability
failures in contexts where multiple signature algorithms are in use.
This document specifies an algorithm for server signature algorithm
selection and an extension that allows a client to advise a server
that specific signature algorithms are supported.

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

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

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

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

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 17:37:55 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

Tim,

> From: Timothy J. Miller [mailto:[email-masked]]=20
>=20
>=20
> > Stefan is saying that the data is not applicant chosen.=20
>=20
> The subject org logotype in 3709 is applicant chosen and has=20
> the same problem.
>=20
> I think the countermeasure of re-ordering extensions is=20
> sufficient, and is probably worth a security consideration in=20
> both specs.
>=20
> -- Tim
>=20

Date: Thu, 30 Jul 2009 16:02:46 -0500
From: "Timothy J. Miller" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: Stefan Santesson <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

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

-- Tim

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

--------------ms090207090701000607030201--

From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D Action:draft-ietf-pkix-cmp-transport-protocols-06.txt 
Date: Thu, 30 Jul 2009 13:45:01 -0700 (PDT)
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 -- Transport Protocols for CMP
	Author(s)       : A. Kapoor, et al.
	Filename        : draft-ietf-pkix-cmp-transport-protocols-06.txt
	Pages           : 24
	Date            : 2009-07-30

This document describes how to layer Certificate Management Protocols
over various transport protocols.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-pkix-cmp-transport-protocols-06.txt

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

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

--NextPart
Content-Type: Message/External-body;
	name="draft-ietf-pkix-cmp-transport-protocols-06.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

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

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 16:42:30 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>
Cc: "Stefan Santesson" <[email-masked]>, "ietf-pkix" <[email-masked]>
Sender: [email-masked]

Tim,

Stefan is saying that the data is not applicant chosen.=20

> From: Timothy J. Miller [mailto:[email-masked]]=20
>=20
> > I do not mean to intrude, but is this data being provided by the=20
> > applicant or is this something structured created by the CA=20
> or gotten=20
> >=20
> > I ask because depending on the answer, this may become pre-image=20
>=20
> I went and refreshed myself on Stevens et.al.'s paper (and=20
> Lenstra's site on colliding X.509) and while I continue to=20
>=20
> The presence of a large applicant-controlled data block like=20
> an image in the extensions would allow a chosen prefix attack=20
> using the extension to house the colliding suffixes (S and=20
> S') and the tail construction (T).=20
> This eliminates the restriction that S||T and S'||T must form=20
> a valid RSA modulus, and opens the possibility that the=20
> attacker can use more near-collision blocks (if the image is=20
> larger than the key).  This would make the attack easier, but=20
>=20
> On the other hand, the larger prefixes P and P' (as they now=20
> include the whole cert up to the extensions) makes it easier=20
> for the CA to confound the chosen-prefix attack.  The CA=20
> would only need to place an unpredictable extension *before*=20
> the id-pe-logotype prior to signing; that's a simple enough=20
> reordering step.
>=20
>=20
> So what would I do?  To be safe, you could do one or more of=20
> the following:
>=20
> - Require the CA to reorder the extensions prior to signing,=20
>=20
> - Specify that the image data is entirely CA controlled, or=20
> contains only minimal data that is applicant controlled (and=20
> that applicant-controlled data in total is less than the key length).=20
> Ideally, take the applicant data from other fields in the=20
>=20
> - Place an upper limit on refStructURI length.  A length less=20
> than the key would probably be sufficient.  Whether this=20
> would be sufficient to house a data URL is an open question;=20
> I don't know.
>=20
>=20
> The reason I say limit applicant data to less than the key=20
> length is because that would restrict the number of collision=20
> blocks the cert image can hold to less than those that can be=20
> held in the modulus. This increases complexity and time for=20
> the attacker if he uses this extension for his collision.  He=20
> can always use the key unless the CA takes other steps to=20
> prevent chosen prefix attacks on its own--which, naturally,=20
> prevents chosen prefix attacks in the extension as well, but=20
> requiring certain CA behavior for *all* certificates is=20
> beyond the scope of this document.  Might be worth a=20
>=20
> All of this presumes that a chosen-prefix attack against SHA=20
> is someday possible, of course.  But it's always good to be=20
>=20
>=20

Date: Thu, 30 Jul 2009 15:33:42 -0500
From: "Timothy J. Miller" <[email-masked]>
To: Santosh Chokhani <[email-masked]>
CC: Stefan Santesson <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

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

-- Tim

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

--------------ms000709090401040607000609--

Date: Thu, 30 Jul 2009 23:21:36 +0300
From: "Moudrick M. Dadashov" <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: Santosh Chokhani <[email-masked]>, "Timothy J. Miller" <[email-masked]>, ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

M.D.

>>>> previously, and you can embed fonts in both PDF/A (it's actually

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 15:55:05 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Timothy J. Miller" <[email-masked]>
Cc: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

Then, a security considerations section describing how this field does
not aid in collision attack should be sufficient.=20

> From: Stefan Santesson [mailto:[email-masked]]=20
>=20
>=20
> Some included elements, like logotype of the subject=20
> organization may be provided by the applicant but the=20
>=20
>=20
>=20
> On 09-07-30 8:55 PM, "Santosh Chokhani"=20
> <[email-masked]> wrote:
>=20
> >=20
> > I do not mean to intrude, but is this data being provided by the=20
> > applicant or is this something structured created by the CA=20
> or gotten=20
> >=20
> > I ask because depending on the answer, this may become pre-image=20
> >=20
> >>=20
> >>=20
> >> So, with all things taken into account, what is your=20
> opinion on what=20
> >> we should do?
> >>=20
> >> Do you argue that we should ignore the feature because it=20
> may enhance=20
> >> hash attacks?
> >>=20
> >> /Stefan
> >>=20
> >>=20
> >>>=20
> >>>> However, I can't escape that it feels a bit warped if we abandon=20
> >>>> useful features because we must design protocols to resist weak=20
> >>>=20
> >>>=20
> >>>=20
> >>>   SVG allows the same RFC2397 data URLs that you were discussing=20
> >>>=20
> >>>=20
> >>=20
> >>=20
> >>=20
> >=20
>=20
>=20
>=20

Date: Thu, 30 Jul 2009 21:52:39 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>, "Timothy J. Miller" <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

/Stefan

>>> previously, and you can embed fonts in both PDF/A (it's actually

Content-class: urn:content-classes:message
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 14:55:55 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Timothy J. Miller" <[email-masked]>
Cc: "ietf-pkix" <[email-masked]>
Sender: [email-masked]

I ask because depending on the answer, this may become pre-image attack
and hence impractical.=20

> From: [email-masked]=20
>=20
>=20
> So, with all things taken into account, what is your opinion=20
> on what we should do?
>=20
> Do you argue that we should ignore the feature because it may=20
> enhance hash attacks?
>=20
> /Stefan
>=20
>=20
> >=20
> >> However, I can't escape that it feels a bit warped if we abandon=20
> >> useful features because we must design protocols to resist weak=20
> >> hashes instead of making sure that we can and do use=20
> >=20
> > It's a risk-management decision, in the end.  The question=20
> is, whose=20
> >=20
> >> On the second point, the data in both SVG and PDF/A are=20
> highly structured.
> >=20
> > I can bury arbitrary amounts of unstructured data in both=20
> SVG and PDF/A.
> >   SVG allows the same RFC2397 data URLs that you were discussing=20
> >=20
> >=20
>=20
>=20
>=20

Date: Thu, 30 Jul 2009 20:31:57 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: "Timothy J. Miller" <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

/Stefan

> previously, and you can embed fonts in both PDF/A (it's actually

Date: Thu, 30 Jul 2009 10:32:59 -0500
From: "Timothy J. Miller" <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

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

-- Tim

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

--------------ms090407000603090905050804--

Date: Thu, 30 Jul 2009 16:43:36 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: "Miller, Timothy J." <[email-masked]>, ietf-pkix <[email-masked]>
Sender: [email-masked]

Understood,

/Stefan

> but any structure in this data is largely immaterial to a collision

From: "Miller, Timothy J." <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, ietf-pkix <[email-masked]>
Date: Thu, 30 Jul 2009 10:16:43 -0400
Subject: RE: Embedded certificate image
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

------=_NextPart_000_0000_01CA10F6.73FB78E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

-- Tim

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

------=_NextPart_000_0000_01CA10F6.73FB78E0--

From: "Jim Schaad" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 12:56:10 +0200
Sender: [email-masked]

> look at it before throwing this option away.

Date: Thu, 30 Jul 2009 10:14:39 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

In-line;

/Stefan

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Embedded certificate image
Date: Thu, 30 Jul 2009 20:01:23 +1200
Sender: [email-masked]

Peter.

Date: Thu, 30 Jul 2009 09:44:30 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Good question.

/Stefan

> In that case why encode it as a URL in the first place?

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Embedded certificate image
Date: Thu, 30 Jul 2009 19:36:30 +1200
Sender: [email-masked]

Peter.

Date: Thu, 30 Jul 2009 08:26:52 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Yoav Nir <[email-masked]>, "'Peter Gutmann'" <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

Exactly

> Email secured by Check Point

From: Yoav Nir <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Thu, 30 Jul 2009 07:26:53 +0300
Subject: RE: Embedded certificate image
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

I guess that if the image is embedded in the URL, you don't really need to =
follow it, just process it locally.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On=
 Behalf Of Peter Gutmann
Sent: Thursday, July 30, 2009 7:10 AM
To: [email-masked]; [email-masked]
Subject: Re: Embedded certificate image

Stefan Santesson <[email-masked]> writes:

>It seems that there are ways to store base64 encoded data in a URL. Since =
all
>images are located through a URL, this opens interesting possibilities if =
the
>URL actually contains the image data itself.

How big are these things going to get?  Anything beyond about 1024 characte=
rs
and you start running into problems with things that reject over-long URLs.

Peter.

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Embedded certificate image
Date: Thu, 30 Jul 2009 16:10:22 +1200
Sender: [email-masked]

Peter.

Date: Wed, 29 Jul 2009 23:55:37 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: ietf-pkix <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3331756543_10385817
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

/Stefan 

--B_3331756543_10385817
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Jim Schaad provided a very interesting idea to this issue at PKIX today<BR=
<BR>
It seems that there are ways to store base64 encoded data in a URL. Since a=
ll images are located through a URL, this opens interesting possibilities if=
 the URL actually contains the image data itself.<BR>
<BR>
I think it could make sense in many situations and environments to provide =
the image inside the certificate in this form.<BR>
<BR>
Russ came up with a concern that all hash attacks loves big chunks of rando=
m data that can be used to create collisions. Counter arguments is that this=
 is only a concern is a week hash is used and also that the data has some st=
ructure as it is base64 encoded.<BR>
<BR>
Jim, could you provide more specific information about the underlying speci=
fication that would enable this?<BR>
<BR>
/Stefan </SPAN></FONT>
</BODY>
</HTML>

--B_3331756543_10385817--

Date: Wed, 29 Jul 2009 11:02:42 +0200
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3331710163_8436001
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

It is my interpretation of the last call discussion that all comments have
been dealt with and that we are ready to hand this document over to the
IESG.

/Stefan

On 09-07-09 3:06 AM, "Stefan Santesson" <[email-masked]> wrote:

> 
> Initiating WG last call on draft-ietf-pkix-new-asn1-05.txt
> Last call ends on Friday July 24.
> 
> /Stefan

--B_3331710163_8436001
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: WGLC on draft-ietf-pkix-new-asn1-05.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>It is my interpretation of the last call discussion that all comments have=
 been dealt with and that we are ready to hand this document over to the IES=
G.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-09 3:06 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-s=
ec.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'><BR>
Initiating WG last call on </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Geneva,=
 Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:9pt'>draft-ietf-pkix-new-=
asn1-05.txt<BR>
Last call ends on Friday July 24.<BR>
<BR>
/Stefan</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3331710163_8436001--

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Reply-to: [email-masked]
CC: <[email-masked]>
Subject: Last Call: draft-ietf-pkix-other-certs (Other Certificates Extension) to Experimental RFC
Date: Tue, 28 Jul 2009 08:10:59 -0700 (PDT)
Sender: [email-masked]

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

- 'Other Certificates Extension '
   <draft-ietf-pkix-other-certs-04.txt> as an Experimental RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-08-11. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-other-certs-04.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17668&rfc_flag=0

Content-class: urn:content-classes:message
Subject: RE: Comments on Draft-ietf-pkix-asn1-translation
Date: Tue, 28 Jul 2009 10:19:16 -0400
From: "Carl Wallace" <[email-masked]>
To: "Jim Schaad" <[email-masked]>
Cc: "Charles W. Gardiner" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Thanks, Jim.  I accepted all of your suggested text and will address ANY
and the integer option of ANY DEFINED BY.  There were three comments I
didn't quite follow.

Section 2.1.2 - The SubjectPublicKeyInfo one is a strained example.  It
assumes that one actually understands the structures from RFC5280.  i.e.
no similar comment to the extnValue case and the adjacent OCTET STRING
cannot been seen.

[CRW] I don't understand your point.  Would you prefer a DSA signature
value as an example or maybe an ASN.1 dump?

Section 2.1.2 - The example might be more interesting if you actually
dumped the Extension object - thus seeing the OCTET STRING wrapping.

[CRW] The example is a dump of the extension, including the OCTET
STRING.  Would you prefer it be scoped just to the OCTET STRING?

Section 2.2.3 -
   The example of the BIT STRING does not have a constraint on it.  You
could refer the the example just above.
  =20
[CRW] The lack of a constraint is noted in the text describing the
example, which is demonstrating usage of prose as a means of
constraining the value.  The purpose of the example is to show that a
constraint cannot be specified relative to a field within the
AlgorithmIdentifier structure.

> From: Jim Schaad [mailto:[email-masked]]
> Sent: Tuesday, July 28, 2009 2:50 PM
> To: Carl Wallace
> Cc: 'Charles W. Gardiner'; [email-masked]
> Subject: Comments on Draft-ietf-pkix-asn1-translation
>=20
> Sorry I did not get to this sooner, I completely missed the
publication
> announcement and did not realize that it had been put out.
>=20
> New Paragraph for section #1.
>=20
> Transforming a new ASN.1 module to an older ASN.1 module can be
> performed in
> a fairly mechanical manner, much of the transformation consists of
> deleting
> new constructs.  Transforming an older ASN.1 module to a newer ASN.1
> module
> can be done fairly mechanically, if one does not wish to move many of
> the
> constraints that are contained in the prose into the ASN.1 module.  If
> the
> constraints are to be added, then the conversion can be a complex
> process.
>=20
> Section 1.1 - Delete paragraph #1 - I think that the only place where
> you
> have these keywords is in the examples, an as such it does not make
> sense to
> have the compliance terms defined.
>=20
> Section 2.1.1 - ANY DEFINED BY can use either an OBJECT IDENTIFIER or
> an
> INTEGER as the identification field.  (See ExtensionAttribute in
> RFC5280.)
>=20
> Section 2.1.1 - Need to talk about a plain ANY - see RFC5280
> AttributeValue
>=20
> Section 2.1.1 - s/does not provide a means/does not provide a formal
> means/
> 	New sentence:  Any associations are done in the comments of the
> module and/or the text of the associated document.
>=20
> Section 2.1.2 - The SubjectPublicKeyInfo one is a strained example.
It
> assumes that one actually understands the structures from RFC5280.
> i.e. no
> similar comment to the extnValue case and the adjacent OCTET STRING
> cannot
> been seen.
>=20
> Section 2.1.2 - The example might be more interesting if you actually
> dumped
> the Extension object - thus seeing the OCTET STRING wrapping.
>=20
> Section 2.1.3 - I want to change the intro here a bit.
>=20
> Information object classes are defined in [].  Object classes allow
> protocol
> designers to associated pieces of data that are in some way
associated.
> In
> the most generic of terms, an Information Object class can be thought
> of as
> a database schema, with Information Object Sets being instances of the
> databases.
>=20
> Unlike type definitions, object classes with the same structure are
not
> equivalent.  Thus if you have:
>=20
>     FOO ::=3D TYPE-IDENTIFIER
>     BAR ::=3D TYPE-IDENTIFIER
>=20
> FOO and BAR are not interchangeable.
>=20
> TYPE-IDENTIFIER is one of the predefined information object classes in
> Annex
> A of [].  This provides for a simple mapping from an OBJECT IDENTIFIER
> to a
> data type.  The tag UNIQUE on &id means that this value may appear
only
> once
> in an Information Object Set, however multiple objects can be defined
> with
> the same &id value.
>=20
> Section 2.2.2 -
>=20
>    Component relation constraints are often used to bind the type
field
>    of an open type to the identifier field.  Using the binding in this
> ways
> allows for
>    a compiler to immediately decode the associated type when the
> containing
> structure is defined.  The following example from
>    [RFC2560] as updated [I-D.ietf-pkix-new-asn1] demonstrates this
>    usage.
>=20
> Section 2.2.2 -
>=20
> In this example, the responseType has a simple constraint applied to
it
> while the response field is constrained to contain a type
>    identified by the responseType field.  The controlling field is
> identified
>=20
>=20
> Section 2.2.2
>=20
> For example, the following example includes invalid
>    atNotation in the defintion of the signature field within the
SIGNED
> paramterized type.
>=20
>  Section 2.2.2
>=20
>    In the above example, the outermost SEQUENCE, SET or CHOICE
relative
>    to the parameters field is the structure named ToBeSigned.
>=20
> 		- the structure is NOT named ToBeSigned.  The type is
not
> actually named, but would probably be best referred to as the SIGNED
> type
> (or SIGNED parameterized type).
>=20
> Section 2.2.3 -
>    The example of the BIT STRING does not have a constraint on it.
You
> could refer the the example just above.
>=20
>=20
> Section 4.1 and Section 4.2
>   We need to have some level of checklists at this point which allows
> people
> to know what they needed to be doing.
>=20
> 4.1
> 1) Remove all Information Set Class, Information Set Object and
> Information
> Set Object Set definitions and imports from the file.
>=20
> 2) Replace all fixed Type Information Set Class element references
with
> the
> fixed type.
>=20
> 3) Delete all simple constraints
>=20
> 4) Delete all CONTAINING statements
>=20
> 5) Convert the remaining Content Constraints into either ANY or ANY
> DEFINED
> BY statements.
>=20
> 6) Remove version and extension markers
>=20
> 7) Hand instantiate all instances of parameterized types.
>=20
>=20
> 4.2  Simple
>=20
> 1) Use TYPE-IDENTIFIER.&Type for "ANY"
>=20
> 2) Use TYPE-IDENTIFIER.&Type for "ANY DEFINED BY ..."
>=20
> 4.2  Complex
>=20
> 1)  Identify each unique class that should be defined based on what
> types of
> things exist.
>=20
> 2)  Define an Information Object Class for each of the classes above
> with
> the appropriate elements.
>=20
> 3)  Define the all of appropriate Information Object Sets based on the
> classes defined in step 2 along with the different places that they
> should
> be used.
>=20
> 4)  Replace ANY by the appropriate class and variable type element.
>=20
> 5)  Replace ANY DEFINED BY with the appropriate variable type element
> and
> the components constraint.
>=20
> 6)  Add any simple constraints as appropriate.
>=20
> 7)  Define any objects and fill in elements for object sets as
> appropriate.
>=20
>=20
> There is probably more -- but this is a good first cut.
>=20
> Jim
>=20
>=20
>=20

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: 'An Internet Attribute Certificate Profile for Authorization' to Proposed Standard
Date: Mon, 27 Jul 2009 07:47:25 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'An Internet Attribute Certificate Profile for Authorization '
   <draft-ietf-pkix-3281update-05.txt> as a Proposed Standard

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

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

This specification defines a profile for the use of X.509 Attribute
Certificates in Internet Protocols.  Attribute certificates may be used in
a wide range of applications and environments covering a broad spectrum of
interoperability goals and a broader spectrum of operational and assurance
requirements.  The goal of this document is to establish a common baseline
for generic applications requiring broad interoperability as well as
limited special purpose requirements.  The profile places emphasis on
attribute certificate support for Internet electronic mail, IPsec, and WWW
security applications.  This document obsoletes RFC 3281.

Working Group Summary

This ID was discussed on the mailing list and at multiple meetings. It is
a simple update to address known errata posted to the RFC editor and to
address an issue identified as a result of developing the
draft-ietf-pkix-authorityclearanceconstraints ID.  The clearance attribute
object identifier didn't match the attribute's X.509 object identifier.

Document Quality

This document is an update of an existing draft and is comparable
in quality to its predecessor.  Note that most of the changes listed in
Appendix C of the document are a result of the long lag time between
updates (e.g., reference updates).

Personnel

Steve Kent is the document Shepherd.  Tim Polk is the responsible
Security Area AD.

RFC Editor Note

License Note:
This document is being forwarded for publication assuming that the
proposed update to the TLP will be completed by the IETF Trust prior
to completion of the RFC publication process.  If that process does not
terminate successfully, please make the following substitution in
Appendix B, replacing RFC XXXX with the number assigned to this RFC:

OLD

   DEFINITIONS IMPLICIT TAGS ::=

NEW

   DEFINITIONS IMPLICIT TAGS ::=

--   Copyright (c) 2009 IETF Trust and the persons identified as
--   authors of the code.  All rights reserved.
--
--   Redistribution and use in source and binary forms, with or without
--   modification, are permitted provided that the following conditions
--   are met:
--
--   - Redistributions of source code must retain the above copyright
--     notice, this list of conditions and the following disclaimer.
--
--   - Redistributions in binary form must reproduce the above copyright
--     notice, this list of conditions and the following disclaimer in
--     the documentation and/or other materials provided with the
--     distribution.
--
--   - Neither the name of Internet Society, IETF or IETF Trust, nor the
--     names of specific contributors, may be used to endorse or promote
--     products derived from this software without specific prior
--     written permission.
--
--
--
--   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
--   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
--   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
--   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
--   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
--   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
--   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
--   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
--   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
--   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
--   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
--   This code is part of RFC XXXX; see the RFC itself for full legal
notices.
-- 
--

Date: Mon, 27 Jul 2009 11:05:59 +0800
From: Zhipeng Zhou <[email-masked]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
To: "'Tom Gindin'" <[email-masked]>
Cc: "'PKIX'" <[email-masked]>
Sender: [email-masked]

That sentence means after parsing the authorization document the Service
Server would exactly know what service rights can be issued to Device A
through the delegate of Device B.
Take an example in the routine life, A asks B to borrow 50 dollars from =
the
bank, then the bank will just lends 50 dollars (not 100) to A through =
the
hands of B.=20
Sure, the wording will be reshaped.
If your second paragraph is about the update of authorization, I feel a =
new
section is needed to explain that part.

Thank you.
Zhipeng
=20

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Tom Gindin
Sent: Sunday, July 26, 2009 5:40 AM
To: Zhipeng Zhou
Cc: 'PKIX'
Subject: RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

        The last sentence of the first sentence on page 6 goes, "Once =
all
these verifications are correct, the Service Server will also catch the
rights that are authorized to Proxy Device B by Request Device A via =
parsing
the elements in the Authorization document."  I am not sure what that =
means,
precisely.  If you mean "will also cache the rights authorized on behalf =
of
Request Device A (via parsing ...) for use through Proxy Device B", then =
B
has no independent set of rights.  That could also be worded "will cache =
the
rights delegated by Request Device A (via parsing
...) to Proxy Device B".
        I assume that A is trying to delegate those rights specified in =
the
ServiceRights field.  What rights does B now have?  It could be the
intersection of A's configured rights with ServiceRights, or the
intersection of B's configured rights with ServiceRights, or the union =
of
B's pre-existing configured rights with the intersection of A's =
configured
rights and ServiceRights.

                Tom Gindin

Zhipeng Zhou <[email-masked]>
07/24/2009 09:44 PM

To
Tom Gindin/Watson/IBM@IBMUS
cc
"'PKIX'" <[email-masked]>
Subject
RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

Thanks for comments.=20
In DRM specification, the Request message will contain the signature of=20
the
Request entity.=20
I think better to give a concise introduction of this point.
Here I am not quite clear of your said " If device B's rights are to be
added to device A's authorization", can you pls give me a use case to =
help
me understand it.
Thank you.
Zhipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =

On
Behalf Of Tom Gindin
Sent: Friday, July 24, 2009 9:46 PM
To: Zhipeng Zhou
Cc: 'Perez, Aram'; 'PKIX'
Subject: RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

        I don't see any signature applied by Proxy Device B, so what is=20
the
point of its certificate in this protocol?  I am not questioning the
function of the proxy itself, just of its certificate.  If device B's=20
rights
are to be added to device A's authorization, should it not authenticate
itself at some point, perhaps through a countersignature?

                Tom Gindin

Zhipeng Zhou <[email-masked]>
Sent by: [email-masked]
07/22/2009 08:57 PM

To
"'Perez, Aram'" <[email-masked]>
cc
"'PKIX'" <[email-masked]>
Subject
RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Aram,
Nice to hear you.
Are you going to Sweden ?
If you can help me gathering more comments in the meeting, that will be=20
exactly wonderful for me.
Thank you.
Zhipeng

From: [email-masked] [mailto:[email-masked]] =

On Behalf Of Perez, Aram
Sent: Thursday, July 23, 2009 3:50 AM
To: PKIX
Subject: Re: Welcome your kind comments on=20
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Zhipeng,

Interesting draft RFC. Here are a few minor comments:

=A1=B0Trusty=A1=B1 is not a word. I believe what you want to say is =
=A1=B0trusted=20
relationship=A1=B1.=20
In section 5.1 you are using the binary format description language we=20
defined in OMA DRM but you have not explained how it is used.

Take care,
Aram

On 7/21/09 8:12 PM, Zhipeng Zhou  wrote:

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind=20
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture=20
<blocked::
http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-00.txt=
>=20

 .
Since some reasons, I could not be in the meeting. Welcome your emails=20
anytime.
Thanks very much.
Zhipeng
=20
-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: [email-masked] <mailto:[email-masked]>=20
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB
=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=
=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************

*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from=20
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information=20

contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or=20
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone=20

or email immediately and delete it!
*************************************************************************=
***
***********************************

=20

To: Zhipeng Zhou <[email-masked]>
Cc: "'PKIX'" <[email-masked]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
From: Tom Gindin <[email-masked]>
Date: Sat, 25 Jul 2009 17:40:07 -0400
Sender: [email-masked]

Date: Sat, 25 Jul 2009 09:44:05 +0800
From: Zhipeng Zhou <[email-masked]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
To: "'Tom Gindin'" <[email-masked]>
Cc: "'PKIX'" <[email-masked]>
Sender: [email-masked]

Thanks for comments.=20
In DRM specification, the Request message will contain the signature of =
the
Request entity.=20
I think better to give a concise introduction of this point.
Here I am not quite clear of your said " If device B's rights are to be
added to device A's authorization", can you pls give me a use case to =
help
me understand it.
Thank you.
Zhipeng

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Tom Gindin
Sent: Friday, July 24, 2009 9:46 PM
To: Zhipeng Zhou
Cc: 'Perez, Aram'; 'PKIX'
Subject: RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

        I don't see any signature applied by Proxy Device B, so what is =
the
point of its certificate in this protocol?  I am not questioning the
function of the proxy itself, just of its certificate.  If device B's =
rights
are to be added to device A's authorization, should it not authenticate
itself at some point, perhaps through a countersignature?

                Tom Gindin

Zhipeng Zhou <[email-masked]>
Sent by: [email-masked]
07/22/2009 08:57 PM

To
"'Perez, Aram'" <[email-masked]>
cc
"'PKIX'" <[email-masked]>
Subject
RE: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Aram,
Nice to hear you.
Are you going to Sweden ?
If you can help me gathering more comments in the meeting, that will be=20
exactly wonderful for me.
Thank you.
Zhipeng

From: [email-masked] [mailto:[email-masked]] =

On Behalf Of Perez, Aram
Sent: Thursday, July 23, 2009 3:50 AM
To: PKIX
Subject: Re: Welcome your kind comments on=20
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Zhipeng,

Interesting draft RFC. Here are a few minor comments:

=A1=B0Trusty=A1=B1 is not a word. I believe what you want to say is =
=A1=B0trusted=20
relationship=A1=B1.=20
In section 5.1 you are using the binary format description language we=20
defined in OMA DRM but you have not explained how it is used.

Take care,
Aram

On 7/21/09 8:12 PM, Zhipeng Zhou  wrote:

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind=20
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture=20
<blocked::
http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architecture-00.txt=
>=20
 .
Since some reasons, I could not be in the meeting. Welcome your emails=20
anytime.
Thanks very much.
Zhipeng
=20
-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: [email-masked] <mailto:[email-masked]>=20
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB
=BB=F2=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=
=CE=BA=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************

*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from=20
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information=20
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or=20
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone=20
or email immediately and delete it!
*************************************************************************=
***
***********************************

=20

To: Zhipeng Zhou <[email-masked]>
Cc: "'Perez, Aram'" <[email-masked]>, "'PKIX'" <[email-masked]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
From: Tom Gindin <[email-masked]>
Date: Fri, 24 Jul 2009 09:46:02 -0400
Sender: [email-masked]

Date: Thu, 23 Jul 2009 08:57:06 +0800
From: Zhipeng Zhou <[email-masked]>
Subject: RE: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
To: "'Perez, Aram'" <[email-masked]>
Cc: "'PKIX'" <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Hi Aram,
Nice to hear you.
Are you going to Sweden ?
If you can help me gathering more comments in the meeting, that will be
exactly wonderful for me.
Thank you.
Zhipeng

  _____ =20

From: [email-masked] [mailto:[email-masked]] =
On
Behalf Of Perez, Aram
Sent: Thursday, July 23, 2009 3:50 AM
To: PKIX
Subject: Re: Welcome your kind comments on
"draft-zhipeng-pkix-drm-proxy-architecture".

Hi Zhipeng,

Interesting draft RFC. Here are a few minor comments:

*	=A1=B0Trusty=A1=B1 is not a word. I believe what you want to say is
=A1=B0trusted relationship=A1=B1.=20

*	In section 5.1 you are using the binary format description language
we defined in OMA DRM but you have not explained how it is used.

Take care,
Aram

On 7/21/09 8:12 PM, Zhipeng Zhou  wrote:

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture
<blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architect=
ure
-00.txt>  .
Since some reasons, I could not be in the meeting. Welcome your emails
anytime.
Thanks very much.
Zhipeng
=20
-----------------------------------------------------

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail: [email-masked] <mailto:[email-masked]>=20
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=
=F2
=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=
=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************

*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone
or email immediately and delete it!
*************************************************************************=
***
***********************************

=20

--Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)
Content-type: text/html; charset=gb2312
Content-transfer-encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Re: Welcome your kind comments on =
"draft-zhipeng-pkix-drm-proxy-architecture".</TITLE>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3562" name=3DGENERATOR></HEAD>
<BODY>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Hi=20
Aram,</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Nice=20
to hear you.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Are=20
you going to Sweden ?</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>If=20
you can help me gathering more comments in the meeting, that will be=20
exactly&nbsp;wonderful for me.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT =
color=3D#0000ff>Thank=20
you.</FONT></SPAN></DIV>
<DIV dir=3Dltr align=3Dleft><SPAN class=3D962024700-23072009><FONT=20
color=3D#0000ff>Zhipeng</FONT></SPAN></DIV><BR>
<DIV class=3DOutlookMessageHeader lang=3Dzh-cn dir=3Dltr align=3Dleft>
<HR tabIndex=3D-1>
<FONT face=3DTahoma size=3D2><B>From:</B> [email-masked]=20
[mailto:[email-masked]] <B>On Behalf Of </B>Perez,=20
Aram<BR><B>Sent:</B> Thursday, July 23, 2009 3:50 AM<BR><B>To:</B>=20
PKIX<BR><B>Subject:</B> Re: Welcome your kind comments on=20
"draft-zhipeng-pkix-drm-proxy-architecture".<BR></FONT><BR></DIV>
<DIV></DIV><FONT face=3DArial><SPAN style=3D"FONT-SIZE: 11pt">Hi=20
Zhipeng,<BR><BR>Interesting draft RFC. Here are a few minor=20
comments:<BR><BR></SPAN></FONT>
<UL>
  <LI><FONT face=3DArial><SPAN style=3D"FONT-SIZE: =
11pt">=A1=B0Trusty=A1=B1 is not a word. I=20
  believe what you want to say is =A1=B0trusted relationship=A1=B1. =
</SPAN></FONT>
  <LI><FONT face=3DArial><SPAN style=3D"FONT-SIZE: 11pt">In section 5.1 =
you are=20
  using the binary format description language we defined in OMA DRM but =
you=20
  have not explained how it is used.<BR></SPAN></FONT></LI></UL><FONT=20
face=3DArial><SPAN style=3D"FONT-SIZE: 11pt"><BR>Take =
care,<BR>Aram<BR><BR><BR>On=20
7/21/09 8:12 PM, Zhipeng Zhou &nbsp;wrote:<BR><BR></SPAN></FONT>
<BLOCKQUOTE><FONT face=3DArial><SPAN style=3D"FONT-SIZE: 11pt">Stefan =
and=20
  all,<BR>I'd ask if the PKIX guys in the Sweden meeting could feeback =
me your=20
  kind comments or suggesions on my =
draft-zhipeng-pkix-drm-proxy-architecture=20
  &lt;blocked::<A=20
  =
href=3D"http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architectur=
e-00.txt">http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architect=
ure-00.txt</A>&gt;=20
  &nbsp;.<BR>Since some reasons, I could not be in the meeting. Welcome =
your=20
  emails anytime.<BR>Thanks very =
much.<BR>Zhipeng<BR>&nbsp;<BR></SPAN><SPAN=20
  style=3D"FONT-SIZE: =
12pt">-----------------------------------------------------<BR><BR>Huawei=
=20
  Software Technologies Co.,Ltd.<BR><BR>Floor 2, Building A, =
NO.48=A3=ACNing Nan=20
  AV.,Nanjing, P.R.of China<BR>Zipcode:210012<BR>E-Mail: </SPAN><FONT=20
  color=3D#808080><FONT size=3D2><SPAN style=3D"FONT-SIZE: 10pt"><A=20
  =
href=3D"[email-masked]">[email-masked]</A></SPAN></FONT></FONT><SPA=
N=20
  style=3D"FONT-SIZE: 12pt"> &lt;<A=20
  href=3D"mailto:[email-masked]">mailto:[email-masked]</A>&gt;=20
  <BR>Phone:(+86) 25-82276771<BR>Fax:(+86) =
25-82276760<BR><BR>Mobile:(+86)=20
  =
13404162849<BR>-----------------------------------------------------<BR><=
BR>&nbsp;<BR><BR>********************************************************=
*******************************************************<BR>=A1=A1=A1=A1=B1=
=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=BE=
=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=C9=
=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=E9=
=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=CA=
=BD=CA=B9=D3=C3<BR><BR>=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=
=BF=BB=F2=B2=BF=B7=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=
=B7=A2=A3=A9=B1=BE=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3<BR><BR>&nbsp=
;&nbsp;&nbsp;&nbsp;=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=
=A3=AC=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=
=A2=BC=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1<BR>************=
*************************************************************************=
**************************<BR><BR><BR>***********************************=
*************************************************************************=
***<BR>&nbsp;&nbsp;&nbsp;&nbsp;This=20
  e-mail and its attachments contain confidential information from =
HUAWEI, which=20
  is intended only for the<BR><BR>person or entity whose address is =
listed=20
  above. Any use of the information contained herein in any=20
  way(including,<BR><BR>but not limited to, total or partial disclosure, =

  reproduction, or dissemination) by persons other than the=20
  intended<BR><BR>recipient(s) is prohibited. =
<BR><BR>&nbsp;&nbsp;&nbsp;&nbsp;If=20
  you receive this e-mail in error, please notify the sender by phone or =
email=20
  immediately and delete=20
  =
it!<BR>******************************************************************=
*********************************************<BR></SPAN><SPAN=20
  style=3D"FONT-SIZE: =
11pt"><BR>&nbsp;<BR><BR></SPAN></FONT></BLOCKQUOTE></BODY></HTML>

--Boundary_(ID_lcf8bGtOSs255QhN1Ir/DQ)--

From: "Perez, Aram" <[email-masked]>
To: PKIX <[email-masked]>
Date: Wed, 22 Jul 2009 12:50:15 -0700
Subject: Re: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

--_000_C68CBB872221Aarampqualcommcom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_C68CBB872221Aarampqualcommcom_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

--_000_C68CBB872221Aarampqualcommcom_--

From: "Jim Schaad" <[email-masked]>
To: "'Charles W. Gardiner'" <[email-masked]>
Cc: "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Wed, 22 Jul 2009 09:57:32 -0700
Sender: [email-masked]

See embedded comments

> From: Charles W. Gardiner [mailto:[email-masked]]
> Sent: Wednesday, July 22, 2009 7:49 AM
> To: Jim Schaad
> Cc: Stefan Santesson; [email-masked]
> Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> At 12:49 AM 7/12/2009, Jim Schaad wrote:
> 
> >Please see the comments embedded in the message.
> 
> <snip>
> 
> 
> >We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
> >These modules have long had such loops in them.  If you go to a larger
> set
> >of modules to compile you will find even worse looping may occur.  Any
> ASN.1
> >compiler must be able to deal with this looping when doing emissions
> to .h
> >files.
> 
>      Alas, I see that X68* does not prohibit looping,so I'll go along.
> 
> 
> > >
> > > 2. The ParamOptions described in AlgorithmInformation is not much
> use
> > > to a
> > > computer.  Translating the shades of necessity to numbers does not
> help
> > > either, particularly as the numbers are not in order of necessity.
> > > (What
> > > percentage of messages having parameters should be rejected if the
> > > preferredAbsent option is specified?)  Most of the options offered,
> > > namely
> > > required, absent and optional, can be achieved by choosing an
> > > appropriate
> > > form of the PARAM statement: for required, just give the TYPE; for
> > > absent,
> > > omit the PARAM statement completely; and for optional, use ARE
> OPTIONAL
> > > in
> > > the PARAM statement.  Perhaps inheritable could be dealt with by a
> > > variant
> > > of the ARE statement, or maybe that condition is implied by OPTION
> >
> >We could order the values of ParamOptions if desired, however I do not
> >actually see any benefit to doing so.  No message should be rejected
> on
> >decoding when preferredAbsent is the value (the parameters should be
> decoded
> >and used), however when messages are encoded then the parameters
> should be
> >omitted.  The presence if this value in the object definition is to
> deal
> >with the text which says "the parameters for an algorithm have the
> type
> >NULL, the parameters SHOULD be omitted, but you MUST accept the
> parameters
> >if they are present."  This is, unfortunately a very common
> construction and
> >we need to represent this so that code can be written by the user (not
> the
> >compiler) that can correctly deal with it.  Having it emitted from the
> ASN.1
> >module rather than hand extracted from the text makes this more
> consistent.
> 
>      The suggestion of accepting one thing when decoding and creating
> another when encoding sounds a little like a distinguished encoding
> rule,
> but it is not in X690.  Won't it create problems in validating
> signatures
> if one decodes a certificate and then encodes the ToBeSigned part
> (perhaps
> changing the parameters) to make a hash?  It sounds like something that
> might be a source of trouble as well as something that requires special
> treatment beyond what X68* specifies.
> 
>      While on that part of the files, I think the CERT KEY USAGE syntax
> is
> somewhat baffling, because there is no way AFAIK to express in ASN.1
> how to
> get from, say, SubjectPublicKeyInfo to the Extension for KeyUsage.  It
> looks like another case where a person might figure it out but a
> computer
> can't without some special code for just that situation.

Both of these constitute META-DATA.  As such it does not directly change how
the encoding, decoding or compiler generated validation is done.  The data
is provided in the module, in a usable form for user code, so that the code
writer does not need to search through the text of the document to find the
same data. 

In terms of how it would be used, consider how one should encode the SHA-1
hash algorithm identifier.  Depending on the document one is reading, it
says either omit the parameter or encode NULL as the parameter.  Having the
information available as part of the meta-data generated by the compiler
allows for code to determine which usage is to be done for a specific
encoding of the SHA-1 hash algorithm.  Having this data generated makes it
easier to be consistent and more correct on such usage.

> 
> 
> > >
> > > 3. The disambiguation of SignatureAlgs and PublicKeys by the use of
> the
> > > file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a
> significant
> > > extension of the language.  Other cases use the name of a
> construct, as
> > > in
> > > the definition of SingleAttribute where it says ATTRIBUTE.&Type,
> but
> > > file
> > > names only appear in IMPORT statements.  Is this use of the
> language
> > > allowed in those difficult X68* documents? It might be simpler to
> > > change
> > > the names of the ambiguous terms in one case, e.g.
> SignatureAlgsOAEP
> > > (assuming that PKIXAlgs-2008 came first).  Or maybe both should be
> > > changed.
> >
> >We looked at doing this both ways, that is using a single common name
> and
> >requiring the prefix of a module, and using distinguished names for
> each
> >module.  I finally decided that the use of a single common name makes
> it
> >clearer what the Object Set is used for and that clarity was worth
> requiring
> >that the module name (as defined in the import statement) be prefixed
> on the
> >single common name.
> >
> >Please note that the reference to a variable as module.name was
> defined as
> >an acceptable part of the language in the 1988 ASN.1 syntax, while it
> was
> >not frequently used, it has always been in the language definition.
> 
>      OK, I see it is allowed.
> 
> 
> > >
> > > 4. PKIXExplicit88 has the statement "AttributeType ::=
> ATTRIBUTE.&id".
> > > Why
> > > not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a
> minor
> > > point, but it seems to me that the present wording requires extra
> work
> > > by a
> > > computer or by a person trying to understand what is meant.  The
> > > simpler
> > > description is used in many other places, so why not this one?
> >
> >I might be willing to think about this type of change for the benefit
> of a
> >person, but not for the compiler.
> 
>      Wouldn't it help the compiler, too?

It makes absolute no difference to my compiler which way it is encoded for
some things, but for some other things it might make a difference.  The
folding of types is done differently for basic types and for types in
restrictions.  I would need to go back and do some careful reading to make
sure that it would all be kosher.   However given that this is the "normal"
way to represent the type information I would lean to leaving it as it is.

Jim

> 
> >Taking your logic one step farther it
> >would make sense to eliminate the use of AttributeType and just use
> OBJECT
> >IDENTIFIER wherever AttributeType is used.  This would make it even
> easier
> >for the person reading the module.  This is one change that could be
> made,
> >however I don't know that I see a real benefit to making the change
> 
>      Making it even easier sounds useful.
> 
> Charlie Gardiner
> 

Date: Wed, 22 Jul 2009 10:48:38 -0400
To: "Jim Schaad" <[email-masked]>
From: "Charles W. Gardiner" <[email-masked]>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Cc: Stefan Santesson <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 12:49 AM 7/12/2009, Jim Schaad wrote:

>Please see the comments embedded in the message.

<snip>

>We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
>These modules have long had such loops in them.  If you go to a larger set
>of modules to compile you will find even worse looping may occur.  Any ASN.1
>compiler must be able to deal with this looping when doing emissions to .h
>files.

     Alas, I see that X68* does not prohibit looping,so I'll go along.

> >
> > 2. The ParamOptions described in AlgorithmInformation is not much use
> > to a
> > computer.  Translating the shades of necessity to numbers does not help
> > either, particularly as the numbers are not in order of necessity.
> > (What
> > percentage of messages having parameters should be rejected if the
> > preferredAbsent option is specified?)  Most of the options offered,
> > namely
> > required, absent and optional, can be achieved by choosing an
> > appropriate
> > form of the PARAM statement: for required, just give the TYPE; for
> > absent,
> > omit the PARAM statement completely; and for optional, use ARE OPTIONAL
> > in
> > the PARAM statement.  Perhaps inheritable could be dealt with by a
> > variant
> > of the ARE statement, or maybe that condition is implied by OPTION
>
>We could order the values of ParamOptions if desired, however I do not
>actually see any benefit to doing so.  No message should be rejected on
>decoding when preferredAbsent is the value (the parameters should be decoded
>and used), however when messages are encoded then the parameters should be
>omitted.  The presence if this value in the object definition is to deal
>with the text which says "the parameters for an algorithm have the type
>NULL, the parameters SHOULD be omitted, but you MUST accept the parameters
>if they are present."  This is, unfortunately a very common construction and
>we need to represent this so that code can be written by the user (not the
>compiler) that can correctly deal with it.  Having it emitted from the ASN.1
>module rather than hand extracted from the text makes this more consistent.

     The suggestion of accepting one thing when decoding and creating 
another when encoding sounds a little like a distinguished encoding rule, 
but it is not in X690.  Won't it create problems in validating signatures 
if one decodes a certificate and then encodes the ToBeSigned part (perhaps 
changing the parameters) to make a hash?  It sounds like something that 
might be a source of trouble as well as something that requires special 
treatment beyond what X68* specifies.

     While on that part of the files, I think the CERT KEY USAGE syntax is 
somewhat baffling, because there is no way AFAIK to express in ASN.1 how to 
get from, say, SubjectPublicKeyInfo to the Extension for KeyUsage.  It 
looks like another case where a person might figure it out but a computer 
can't without some special code for just that situation.

> >
> > 3. The disambiguation of SignatureAlgs and PublicKeys by the use of the
> > file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant
> > extension of the language.  Other cases use the name of a construct, as
> > in
> > the definition of SingleAttribute where it says ATTRIBUTE.&Type, but
> > file
> > names only appear in IMPORT statements.  Is this use of the language
> > allowed in those difficult X68* documents? It might be simpler to
> > change
> > the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP
> > (assuming that PKIXAlgs-2008 came first).  Or maybe both should be
> > changed.
>
>We looked at doing this both ways, that is using a single common name and
>requiring the prefix of a module, and using distinguished names for each
>module.  I finally decided that the use of a single common name makes it
>clearer what the Object Set is used for and that clarity was worth requiring
>that the module name (as defined in the import statement) be prefixed on the
>single common name.
>
>Please note that the reference to a variable as module.name was defined as
>an acceptable part of the language in the 1988 ASN.1 syntax, while it was
>not frequently used, it has always been in the language definition.

     OK, I see it is allowed.

> >
> > 4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".
> > Why
> > not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor
> > point, but it seems to me that the present wording requires extra work
> > by a
> > computer or by a person trying to understand what is meant.  The
> > simpler
> > description is used in many other places, so why not this one?
>
>I might be willing to think about this type of change for the benefit of a
>person, but not for the compiler.

     Wouldn't it help the compiler, too?

>Taking your logic one step farther it
>would make sense to eliminate the use of AttributeType and just use OBJECT
>IDENTIFIER wherever AttributeType is used.  This would make it even easier
>for the person reading the module.  This is one change that could be made,
>however I don't know that I see a real benefit to making the change

     Making it even easier sounds useful.

Charlie Gardiner

Date: Wed, 22 Jul 2009 11:12:53 +0800
From: Zhipeng Zhou <[email-masked]>
Subject: Welcome your kind comments on "draft-zhipeng-pkix-drm-proxy-architecture".
To: [email-masked]
Cc: [email-masked]
Sender: [email-masked]

This is a multi-part message in MIME format.

--Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)
Content-type: text/plain; charset=gb2312
Content-transfer-encoding: quoted-printable

Stefan and all,
I'd ask if the PKIX guys in the Sweden meeting could feeback me your =
kind
comments or suggesions on my draft-zhipeng-pkix-drm-proxy-architecture
<blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-architect=
ure
-00.txt>  .
Since some reasons, I could not be in the meeting. Welcome your emails
anytime.
Thanks very much.
Zhipeng
=20

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

Huawei Software Technologies Co.,Ltd.

Floor 2, Building A, NO.48=A3=ACNing Nan AV.,Nanjing, P.R.of China
Zipcode:210012
E-Mail:  <mailto:[email-masked]> [email-masked]
Phone:(+86) 25-82276771
Fax:(+86) 25-82276760

Mobile:(+86) 13404162849
-----------------------------------------------------

=20

*************************************************************************=
***
***********************************
=A1=A1=A1=A1=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=
=AA=B9=AB=CB=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=
=CB=CD=B8=F8=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=
=F2
=C8=BA=D7=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=
=CE=D0=CE=CA=BD=CA=B9=D3=C3

=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=D6=B5=
=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=D3=CA=
=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3

    =
=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=C7=EB=C4=FA=C1=
=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=FE=C8=CB=B2=A2=
=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1
*************************************************************************=
***
***********************************

*************************************************************************=
***
***********************************
    This e-mail and its attachments contain confidential information =
from
HUAWEI, which is intended only for the

person or entity whose address is listed above. Any use of the =
information
contained herein in any way(including,

but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended

recipient(s) is prohibited.=20

    If you receive this e-mail in error, please notify the sender by =
phone
or email immediately and delete it!
*************************************************************************=
***
***********************************

=20

--Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)
Content-type: text/html; charset=gb2312
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=3Dgb2312">
<META content=3D"MSHTML 6.00.2900.3562" name=3DGENERATOR></HEAD>
<BODY>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>Stefan and=20
all,</FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>I'd =
ask&nbsp;if&nbsp;the=20
PKIX&nbsp;guys in the Sweden meeting could feeback me your kind comments =
or=20
suggesions on my <A=20
title=3D"blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-a=
rchitecture-00.txt&#10;http://tools.ietf.org/id/draft-zhipeng-pkix-drm-pr=
oxy-architecture-00.txt"=20
href=3D"blocked::http://tools.ietf.org/id/draft-zhipeng-pkix-drm-proxy-ar=
chitecture-00.txt">draft-zhipeng-pkix-drm-proxy-architecture</A><FONT=20
color=3D#000000> .</FONT></FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>Since some =
reasons, I could=20
not be in the meeting. Welcome your emails anytime.</FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT face=3DArial>Thanks very=20
much.</FONT></SPAN></DIV>
<DIV><SPAN class=3D242480603-22072009><FONT =
face=3DArial>Zhipeng</FONT></SPAN></DIV>
<DIV>&nbsp;</DIV><?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:SmartTagType =
name=3D"City"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"country-region"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype><o:SmartTagType=20
name=3D"place"=20
namespaceuri=3D"urn:schemas-microsoft-com:office:smarttags"></o:SmartTagT=
ype>
<OBJECT id=3Dieooui =
classid=3Dclsid:38481807-CA0E-42D2-BF39-B33AF135CC4D></OBJECT>
<STYLE>
st1\:*{behavior:url(#ieooui) }
</STYLE>

<STYLE>
<!--
 /* Font Definitions */
 @font-face
	{font-family:=CB=CE=CC=E5;
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-alt:SimSun;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:"\@=CB=CE=CC=E5";
	panose-1:2 1 6 0 3 1 1 1 1 1;
	mso-font-charset:134;
	mso-generic-font-family:auto;
	mso-font-pitch:variable;
	mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
	{font-family:Albertus;
	mso-font-alt:"Times New Roman";
	mso-font-charset:0;
	mso-generic-font-family:auto;
	mso-font-pitch:auto;
	mso-font-signature:0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-parent:"";
	margin:0cm;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;
	mso-bidi-font-family:=CB=CE=CC=E5;}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{color:blue;
	text-decoration:underline;
	text-underline:single;}
p.section1, li.section1, div.section1
	{mso-style-name:section1;
	mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:0cm;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:=CB=CE=CC=E5;
	mso-bidi-font-family:=CB=CE=CC=E5;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
span.GramE
	{mso-style-name:"";
	mso-gram-e:yes;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;
	mso-header-margin:42.55pt;
	mso-footer-margin:49.6pt;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</STYLE>

<DIV class=3DSection1>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-no-proof: yes"></SPAN><SPAN=20
lang=3DEN-US>-----------------------------------------------------</SPAN>=
<SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; =
mso-bidi-font-family: Arial"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: =
char"><SPAN=20
lang=3DEN-US>Huawei Software Technologies Co.<SPAN=20
class=3DGramE>,Ltd</SPAN>.<o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: =
char"><SPAN=20
lang=3DEN-US>Floor 2, Building A, NO.48</SPAN>=A3=AC<SPAN =
class=3DSpellE><SPAN=20
lang=3DEN-US>Ning</SPAN></SPAN><SPAN lang=3DEN-US> Nan <SPAN =
class=3DSpellE>AV.<SPAN=20
class=3DGramE>,<?xml:namespace prefix =3D st1 ns =3D=20
"urn:schemas-microsoft-com:office:smarttags" /><st1:City=20
w:st=3D"on">Nanjing</st1:City>, </SPAN>P.R.of</SPAN> <st1:country-region =

w:st=3D"on"><st1:place=20
w:st=3D"on">China</st1:place></st1:country-region><BR>Zipcode:210012<BR>E=
-Mail: <A=20
title=3Dmailto:[email-masked] =
href=3D"mailto:[email-masked]"><SPAN=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: Albertus; =
mso-bidi-font-family: Arial">[email-masked]</SPAN></A><BR>Phone:(+86) =

25-82276771<BR>Fax:(+86) 25-82276760</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: =
Albertus"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt; LAYOUT-GRID-MODE: =
char"><SPAN=20
class=3DGramE><SPAN lang=3DEN-US>Mobile:</SPAN></SPAN><SPAN =
lang=3DEN-US>(+86)=20
13404162849<BR>-----------------------------------------------------</SPA=
N><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10.5pt; COLOR: gray; FONT-FAMILY: =
Albertus"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
lang=3DEN-US><o:p>&nbsp;</o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
lang=3DEN-US>************************************************************=
***************************************************<BR></SPAN>=A1=A1=A1=A1=
=B1=BE=D3=CA=BC=FE=BC=B0=C6=E4=B8=BD=BC=FE=BA=AC=D3=D0=BB=AA=CE=AA=B9=AB=CB=
=BE=B5=C4=B1=A3=C3=DC=D0=C5=CF=A2=A3=AC=BD=F6=CF=DE=D3=DA=B7=A2=CB=CD=B8=F8=
=C9=CF=C3=E6=B5=D8=D6=B7=D6=D0=C1=D0=B3=F6=B5=C4=B8=F6=C8=CB=BB=F2=C8=BA=D7=
=E9=A1=A3=BD=FB=D6=B9=C8=CE=BA=CE=C6=E4=CB=FB=C8=CB=D2=D4=C8=CE=BA=CE=D0=CE=
=CA=BD=CA=B9=D3=C3<SPAN=20
lang=3DEN-US style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1=20
style=3D"MARGIN: 0cm 0cm =
0pt">=A3=A8=B0=FC=C0=A8=B5=AB=B2=BB=CF=DE=D3=DA=C8=AB=B2=BF=BB=F2=B2=BF=B7=
=D6=B5=D8=D0=B9=C2=B6=A1=A2=B8=B4=D6=C6=A1=A2=BB=F2=C9=A2=B7=A2=A3=A9=B1=BE=
=D3=CA=BC=FE=D6=D0=B5=C4=D0=C5=CF=A2=A1=A3<SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp;=20
</SPAN></SPAN>=C8=E7=B9=FB=C4=FA=B4=ED=CA=D5=C1=CB=B1=BE=D3=CA=BC=FE=A3=AC=
=C7=EB=C4=FA=C1=A2=BC=B4=B5=E7=BB=B0=BB=F2=D3=CA=BC=FE=CD=A8=D6=AA=B7=A2=BC=
=FE=C8=CB=B2=A2=C9=BE=B3=FD=B1=BE=D3=CA=BC=FE=A3=A1<SPAN=20
lang=3DEN-US><BR>********************************************************=
*******************************************************</SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN=20
lang=3DEN-US><BR>********************************************************=
*******************************************************<BR><SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp; </SPAN>This e-mail and its =

attachments contain confidential information from HUAWEI, which is =
intended only=20
for the</SPAN><SPAN lang=3DEN-US style=3D"FONT-SIZE: =
10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US>person or entity=20
whose address is listed above. Any use of the information contained =
herein in=20
any way(including,</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US>but =
not limited=20
to, total or partial disclosure, reproduction, or dissemination) by =
persons=20
other than the intended</SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US>recipient(s) is=20
prohibited. </SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt"><o:p></o:p></SPAN></P>
<P class=3Dsection1 style=3D"MARGIN: 0cm 0cm 0pt"><SPAN =
lang=3DEN-US><SPAN=20
style=3D"mso-tab-count: 1">&nbsp;&nbsp;&nbsp; </SPAN>If you receive this =
e-mail in=20
error, please notify the sender by phone or email immediately and delete =

it!<BR>******************************************************************=
*********************************************</SPAN></P></DIV>
<DIV>&nbsp;</DIV></BODY></HTML>

--Boundary_(ID_Y+qK7eWpt701WL1uKWqtFQ)--

Date: Tue, 21 Jul 2009 23:37:58 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Thomas Hardjono <[email-masked]>, "'ietf-pkix'" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3331064279_2138730
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Thomas,

One aspect that is almost forgotten currently in the hype is that we need
solutions for electronic signatures and encryption and identification of
services to users, not just single sign on. Identity federation will not
solve all these cases and we may end up with parallel solutions for
different use cases. We might want to hide the technology for the users, bu=
t
we have also hidden the important result of the technology... To display th=
e
certified identity of the identified opponent.

I do agree on your conclusion, but I have more seen the cert image as a goo=
d
candidate image for an information card, but never the need to store an
information card in a certificate.

/Stefan

On 09-07-21 10:13 PM, "Thomas Hardjono" <[email-masked]> wrote:

> Hi Stefan,
> =20
> In my (limited) view of looking at where the world of identity & ID feder=
ation
> is heading, it seems that X509 certs could have a major role (depending o=
n how
> it is architected). The problem is that the complexity of X509 (perceived=
 and
> real) have really put-off people in the identity space from considering i=
t for
> =20
> So for X509 to play a role in the new identity =B3layer=B2 on the Internet, i=
t
> really should remain technology-under-the-hood that the average users sho=
uld
> never see.  In fact, I think the PKIX community should right now be think=
ing
> about (a) how X509 can complement (not replace or supplant) other emergin=
g
> =20
> To the end of making an X.509 more human-friendly and more =B3identity
> friendly=B2, embedding an image inside a cert could be a very attractive wa=
y to
> among identity metasystem infrastructure entities (think SAML stuff, and =
WS-S
> stuff over SOAP), I don=B9t the size of an X509+image cert matters any more=
 at
> =20
> =20
> =20
> =20
>=20
> =20
>=20
> When discussing the particular issue at hand, it has just been considered=
 in
> However I agree that if we would create such extension, that we should ma=
ke it
>=20
>=20
>=20
>=20
>=20
> =20
> Has there been any thought about making such an extension =B3generic=B2 enoug=
h
> that it could reference other human-friendly objects (e.g. InfoCard, Open=
ID
> identity, etc. etc).
> =20
> /thomas/
> =20
> =20
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
>=20
>=20
>=20
> capacity to allow certificate images to be stored in the certificate itse=
lf.
> By storing the image in the certificate, we could save a network retrieva=
l.
>=20
> certificate occasionally needs to be used in a constrained environment an=
d the
> fact that the base standard that we are updating (RFC 3709) simply does n=
ot
> allow embedded images.
>=20
> One way to do this could be to store images in a separate extension and t=
hen
> define  a way to reference that image from the logotype extension through=
 an
> internal reference.
>=20
> My proposed resolution is to exclude local storage from the current draft=
.
>=20
> If a strong reason emerges to allow local storage, then this can be defin=
ed in
>=20
> /Stefan=20
>=20

--B_3331064279_2138730
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Thomas,<BR>
<BR>
We do indeed see a wave of identity federation in many areas. In many aspec=
ts this is very healthy. We have seen huge success in the academic world. We=
 can further see that the European Union is betting heavily on identity fede=
ration to solve cross border identity recognition. However, in other aspects=
 we are getting extremely close to truth #6 of networking (RFC 1925). It is =
is easier to move a problem around than it is to solve it. (Thanks Peter Gut=
man for reminding me of this truth).<BR>
<BR>
One aspect that is almost forgotten currently in the hype is that we need s=
olutions for electronic signatures and encryption and identification of serv=
ices to users, not just single sign on. Identity federation will not solve a=
ll these cases and we may end up with parallel solutions for different use c=
ases. We might want to hide the technology for the users, but we have also h=
idden the important result of the technology... To display the certified ide=
ntity of the identified opponent.<BR>
<BR>
I do agree on your conclusion, but I have more seen the cert image as a goo=
d candidate image for an information card, but never the need to store an in=
formation card in a certificate. <BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 10:13 PM, &quot;Thomas Hardjono&quot; &lt;<a href=3D"ietf@hardjon=
o.net">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D=
"><FONT FACE=3D"Courier New">Hi Stefan,<BR>
&nbsp;<BR>
In my (limited) view of looking at where the world of identity &amp; ID fed=
eration is heading, it seems that X509 certs could have a major role (depend=
ing on how it is architected). The problem is that the complexity of X509 (p=
erceived and real) have really put-off people in the identity space from con=
sidering it for direct use as an identity structure.<BR>
&nbsp;<BR>
So for X509 to play a role in the new identity &#8220;layer&#8221; on the I=
nternet, it really should remain technology-under-the-hood that the average =
users should never see. &nbsp;In fact, I think the PKIX community should rig=
ht now be thinking about (a) how X509 can complement (not replace or supplan=
t) other emerging identity structures, and (b) how a PKI-infrastructure coul=
d support the identity metasystem infrastructure that organizations are roll=
ing-out.<BR>
&nbsp;<BR>
To the end of making an X.509 more human-friendly and more &#8220;identity =
friendly&#8221;, embedding an image inside a cert could be a very attractive=
 way to bridge the two worlds. Given the large amounts of traffic being exch=
anged among identity metasystem infrastructure entities (think SAML stuff, a=
nd WS-S stuff over SOAP), I don&#8217;t the size of an X509+image cert matte=
rs any more at the identity layer.<BR>
&nbsp;<BR>
/thomas/<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> Stefan Santesson [<a href=3D"mailto=
:[email-masked]">mailto:[email-masked]</a>] <BR>
<B>Sent:</B> Monday, July 20, 2009 5:43 PM<BR>
<B>To:</B> Thomas Hardjono; 'ietf-pkix'<BR>
<B>Subject:</B> Re: Embedded certificate image<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>Hi Thomas,<BR>
<BR>
When discussing the particular issue at hand, it has just been considered i=
n relation to certificate images.<BR>
However I agree that if we would create such extension, that we should make=
 it generic.<BR>
<BR>
I think that is yet another good argument that such extension should be sep=
arated from the certimage work.<BR>
<BR>
What is your assessment on the actual need to store objects like an informa=
tion card inside a certificate?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-20 10:44 PM, &quot;Thomas Hardjono&quot; &lt;<a href=3D"ietf@hardjon=
o.net">[email-masked]</a>&gt; wrote:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D"><FONT FACE=
=3D"Courier New">Stefan,<BR>
&nbsp;<BR>
Has there been any thought about making such an extension &#8220;generic&#8=
221; enough that it could reference other human-friendly objects (e.g. InfoC=
ard, OpenID identity, etc. etc).<BR>
&nbsp;<BR>
/thomas/<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Monday, July 20, 2009 1:50 PM<BR>
<B>To:</B> ietf-pkix<BR>
<B>Subject:</B> Embedded certificate image<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>This is the first of two unresolved issues listed in the Cer=
timage draft.<BR>
<BR>
Is there any reason to provide any means to embed certificate images in a c=
ertificate.<BR>
<BR>
The reason why this might be a valid option is because we often use certifi=
cates in environments that have sufficient bandwidth and memory capacity to =
allow certificate images to be stored in the certificate itself. By storing =
the image in the certificate, we could save a network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage if a c=
ertificate occasionally needs to be used in a constrained environment and th=
e fact that the base standard that we are updating (RFC 3709) simply does no=
t allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension and the=
n define &nbsp;a way to reference that image from the logotype extension thr=
ough an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be defined=
 in a separate draft.<BR>
<BR>
/Stefan <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3331064279_2138730--

From: "Jim Schaad" <[email-masked]>
To: "'Sean Turner'" <[email-masked]>, <[email-masked]>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Tue, 21 Jul 2009 14:22:56 -0700
Sender: [email-masked]

The advantage of using the second option is that certificates which use the,
for PKIX, deprecated options would still decode correctly.

The disadvantage of using the second option is that a small piece of ASN.1
in the CMS world would need to be modified for some obsolete text where a
NULL was permitted in an AlgorithmParameter to say that the same EC
parameters were being used (rather than being in some way implicit).

My personal preference is the second option merely because it is the least
restrictive, but I would be willing to accept either one.

Jim

> [email-masked]] On Behalf Of Sean Turner
> Sent: Tuesday, July 14, 2009 6:38 AM
> To: [email-masked]
> Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> 
> We need to align ECParameters with RFC 5480.  PKIX agreed to comment
> out
>   the specifiedCurve and namedCurve choices.  I leave the choice to you
> as to which way you'd like to fix it (though I tend to lean towards the
> 1st):
> 
> ECParameters ::= CHOICE {
>   namedCurve      CURVE.&id({NamedCurve})
>   -- implicitCurve   NULL
>   -- specifiedCurve  SpecifiedECDomain
>   -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
>   -- Details for specifiedCurve can be found in [X9.62].
>   -- Any future additions to this CHOICE should be coordinated
>   -- with ANSI X.9.
> }
> 
> or
> 
> ECParameters ::= CHOICE {
>   namedCurve      CURVE.&id({NamedCurve}),
>   implicitCurve   NULL,
>   specifiedCurve  SpecifiedECDomain
>   -- specifiedCurve MUST NOT be used in PKIX.
>   -- Details for SpecifiedECDomain can be found in [X9.62].
>   -- Any future additions to this CHOICE should be coordinated
>   -- with ANSI X.9.
> }
> WITH COMPONENTS {namedCurve PRESENT}
> 
> spt

Date: Tue, 21 Jul 2009 23:16:50 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, Anders Rundgren <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3331063011_2072136
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Anders,

As we have concluded there are some variants for storing a locally selected
image with the certificate for local use. That is, in a way that does
benefit the certificate holder but not the relying party.
Information Card is one such technology and the system you are working on i=
s
another.

/Stefan

On 09-07-21 11:57 AM, "Stefan Santesson" <[email-masked]> wrote:

> I=B9m sorry Anders, but totally fail to see how this has anything to do wit=
h the
> discussed issue.
>=20
> I don=B9t see any =B3competing proposal=B2
>=20
>=20
>=20
>=20
> On 09-07-21 11:10 AM, "Anders Rundgren" <[email-masked]> wrote=
:
>=20
>>=20
>>=20
>>=20
>>=20
>> yesterdays' problems (like PKI middleware), ignoring higher-level aspect=
s
>>=20
>> finally is here while interoperable and generally available authenticati=
on
>> solutions are not.   The described solution is also designed to fill thi=
s
>>=20
>>=20
>>> =20
>>>=20
>>> obtained it, creating the situation where the image is locally stored b=
ut
>>>=20
>>>=20
>>>=20
>>>=20
>>>=20
>>>  =20
>>> =20
>>>> =20
>>>>=20
>>>>=20
>>>>    =20
>>>> =20
>>>>> =20
>>>>> This is the first of two unresolved issues listed in the Certimage dr=
aft.
>>>>>=20
>>>>>=20
>>>>> certificates in environments that have sufficient bandwidth and memor=
y
>>>>>=20
>>>>>=20
>>>>>=20
>>>>> My proposed resolution is to exclude local storage from the current d=
raft.
>>>>> Defining local embedding is adding unnecessary complexity to the draf=
t.
>>>>>=20
>>>>>=20
>>>>> /Stefan=20
>>>>>      =20
>>>>> =20
>>>> =20
>>> =20
>>>=20
>>>=20
>>>=20
>>>  =20
>>=20
>>=20
>=20

--B_3331063011_2072136
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Anders,<BR>
<BR>
Thanks for the clarifications provided off-line.<BR>
I just wanted to recap here on the list.<BR>
<BR>
As we have concluded there are some variants for storing a locally selected=
 image with the certificate for local use. That is, in a way that does benef=
it the certificate holder but not the relying party.<BR>
Information Card is one such technology and the system you are working on i=
s another.<BR>
<BR>
As I think we concluded, these represent other use cases than the one the c=
ertimage draft is addressing and IMO they are more complementary than compet=
ing in the sense that if the issuer has provided an image, then it will be a=
 good candidate image for local use.<BR>
<BR>
Nothing in this suggest that the certimage draft should provide a solution =
for local storage of the image data.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 11:57 AM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-=
sec.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>I&#8217;m sorry Anders, but totally fail to see =
how this has anything to do with the discussed issue.<BR>
<BR>
I don&#8217;t see any &#8220;competing proposal&#8221;<BR>
Is there any chance you could give me a distinct short explanation in one s=
entence or two that would help me understand.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-07-21 11:10 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundg=
[email-masked]">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Stefan,<BR>
<BR>
&gt;I'm not sure what you mean by &quot;competing&quot; proposal<BR>
<BR>
If you look back a few months on my comments to the cert-image I-D<BR>
you'll find pointers to an entirely different proposal which is built<BR>
on top of a new provisioning protocol which in turn builds on a<BR>
revised TPM-based key storage scheme:<BR>
<a href=3D"http://webpki.org/papers/keygen2/secure-key-store.pdf">http://webp=
ki.org/papers/keygen2/secure-key-store.pdf</a><BR>
<BR>
The &quot;humble&quot; goal is unifying Information Cards, PKI, and OTP bec=
ause<BR>
they are all useful but support quite distinct use-cases.<BR>
<BR>
Isn't this incredibly difficult to succeed with? &nbsp;Probably, but there =
is<BR>
no competition at least, since most people appear awfully busy solving<BR>
yesterdays' problems (like PKI middleware), ignoring higher-level aspects<B=
R>
of tokens such as utility in the real world where you need to deal with<BR>
multiple identities and technologies.<BR>
<BR>
In addition, &quot;iPhone &amp; friends&quot; have shown that the Mobile In=
ternet<BR>
finally is here while interoperable and generally available authentication<=
BR>
solutions are not. &nbsp;&nbsp;The described solution is also designed to f=
ill this vacuum.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
Anders,<BR>
<BR>
I'm not sure what you mean by &quot;competing&quot; proposal, but a reasona=
ble<BR>
behavior by the client is to cache the certificate image once it has<BR>
obtained it, creating the situation where the image is locally stored but<B=
R>
not embedded.<BR>
<BR>
But you won't get away from that first retrieval.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 8:33 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundgr=
[email-masked]">[email-masked]</a>&gt; &lt;<a href=3D"mailto:anders.r=
[email-masked]">mailto:[email-masked]</a>&gt; &nbsp;wrote:<BR>
<BR>
&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
In the &quot;competing&quot; proposal, certificate images are locally store=
d<BR>
but not embedded in certificates. &nbsp;This is a viable solution when<BR>
images are only to be consumed by the end-user. &nbsp;For external<BR>
consumption (which I consider an entirely different use-case),<BR>
the existing I-D seems quite sufficient.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
This is the first of two unresolved issues listed in the Certimage draft.<B=
R>
<BR>
Is there any reason to provide any means to embed certificate images<BR>
in a certificate.<BR>
<BR>
The reason why this might be a valid option is because we often use<BR>
certificates in environments that have sufficient bandwidth and memory<BR>
capacity to allow certificate images to be stored in the certificate<BR>
itself. By storing the image in the certificate, we could save a<BR>
network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage<BR>
if a certificate occasionally needs to be used in a constrained<BR>
environment and the fact that the base standard that we are updating<BR>
(RFC 3709) simply does not allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension<BR>
and then define &nbsp;a way to reference that image from the logotype<BR>
extension through an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be<BR>
defined in a separate draft.<BR>
<BR>
/Stefan <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3331063011_2072136--

From: "Thomas Hardjono" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'ietf-pkix'" <[email-masked]>
Subject: RE: Embedded certificate image
Date: Tue, 21 Jul 2009 16:13:33 -0400
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_003D_01CA0A1E.367BCC60
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Stefan,

 
 
/thomas/

 
Hi Thomas,

/Stefan

 
/thomas/

/Stefan 

------=_NextPart_000_003D_01CA0A1E.367BCC60
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 12">
<meta name=3DOriginator content=3D"Microsoft Word 12">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>Re: Embedded certificate image</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
  <o:DoNotRelyOnCSS/>
  <o:TargetScreenSize>1024x768</o:TargetScreenSize>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:DoNotExpandShiftReturn/>
   <w:BreakWrappedTables/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val=3D"Cambria Math"/>
   <m:brkBin m:val=3D"before"/>
   <m:brkBinSub m:val=3D"--"/>
   <m:smallFrac m:val=3D"off"/>
   <m:dispDef/>
   <m:lMargin m:val=3D"0"/>
   <m:rMargin m:val=3D"0"/>
   <m:defJc m:val=3D"centerGroup"/>
   <m:wrapIndent m:val=3D"1440"/>
   <m:intLim m:val=3D"subSup"/>
   <m:naryLim m:val=3D"undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"=20
  DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"=20
  LatentStyleCount=3D"267">
  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
  <w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
  <w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
  <w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense =
Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"37" =
Name=3D"Bibliography"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1610611985 1073750139 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627400839 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Courier New";
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-qformat:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>Hi Stefan,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>In my (limited) view of looking at where the world of =
identity
&amp; ID federation is heading, it seems that X509 <span =
class=3DSpellE>certs</span>
could have a major role (depending on how it is architected). The =
problem is
that the complexity of X509 (perceived and real) have really put-off =
people in
the identity space from considering it for direct use as an identity =
structure.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>So for X509 to play a role in the new identity =
&#8220;layer&#8221;
on the Internet, it really should remain technology-under-the-hood that =
the
average users should never see.<span style=3D'mso-spacerun:yes'>&nbsp; =
</span>In
fact, I think the PKIX community should right now be thinking about (a) =
how
X509 can complement (not replace or supplant) other emerging identity =
structures,
and (b) how a PKI-infrastructure could support the identity <span =
class=3DSpellE>metasystem</span>
infrastructure that organizations are =
rolling-out.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>To the end of making an X.509 more human-friendly and =
more &#8220;identity
friendly&#8221;, embedding an image inside a cert could be a very =
attractive
way to bridge the two worlds. Given the large amounts of traffic being
exchanged among identity <span class=3DSpellE>metasystem</span> =
infrastructure entities
(think SAML stuff, and WS-S stuff over SOAP), I don&#8217;t the size of =
an X509+image
cert matters any more at the identity =
layer.<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>/thomas/<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

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

<div>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif";mso-fareast-font-family:"Times New =
Roman";
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:
"Times New Roman"'> Stefan Santesson [mailto:[email-masked]] <br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 20, =
2009 5:43
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> Thomas Hardjono; =
'ietf-pkix'<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Re: Embedded =
certificate
image<o:p></o:p></span></font></p>

</div>

</div>

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

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
face=3DCalibri><span
style=3D'font-size:11.0pt;font-family:"Calibri","sans-serif";mso-fareast-=
font-family:
"Times New Roman"'>Hi Thomas,<br>
<br>
When discussing the particular issue at hand, it has just been =
considered in
relation to certificate images.<br>
However I agree that if we would create such extension, that we should =
make it
generic.<br>
<br>
I think that is yet another good argument that such extension should be
separated from the certimage work.<br>
<br>
What is your assessment on the actual need to store objects like an =
information
card inside a certificate?<br>
<br>
/Stefan<br>
<br>
<br>
On 09-07-20 10:44 PM, &quot;Thomas Hardjono&quot; &lt;<a
href=3D"[email-masked]">[email-masked]</a>&gt; =
wrote:</span></font><span
style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p></o:p></span></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'><font size=3D2 =
color=3D"#1f497d"
face=3D"Courier New"><span =
style=3D'font-size:11.0pt;font-family:"Courier New";
mso-fareast-font-family:"Times New Roman";color:#1F497D'>Stefan,<br>
&nbsp;<br>
Has there been any thought about making such an extension =
&#8220;generic&#8221;
enough that it could reference other human-friendly objects (e.g. =
InfoCard,
OpenID identity, etc. etc).<br>
&nbsp;<br>
/thomas/<br>
&nbsp;<br>
&nbsp;<br>
&nbsp;<br>
</span></font><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New =
Roman"'><br>
</span></font><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif";mso-fareast-font-family:"Times New =
Roman";
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:
"Times New Roman"'> <a =
href=3D"[email-masked]">[email-masked]</a>
[<a =
href=3D"mailto:[email-masked]">mailto:owner-ietf-pkix@mail.=
imc.org</a>]
<b><span style=3D'font-weight:bold'>On Behalf Of </span></b>Stefan =
Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 20, =
2009 1:50
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ietf-pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Embedded =
certificate
image<br>
</span></font><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><br>
</span><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt;font-family:
"Calibri","sans-serif";mso-fareast-font-family:"Times New Roman"'>This =
is the
first of two unresolved issues listed in the Certimage draft.<br>
<br>
Is there any reason to provide any means to embed certificate images in =
a
certificate.<br>
<br>
The reason why this might be a valid option is because we often use =
certificates
in environments that have sufficient bandwidth and memory capacity to =
allow
certificate images to be stored in the certificate itself. By storing =
the image
in the certificate, we could save a network retrieval.<br>
<br>
The main counter argument is that it would be a serious disadvantage if =
a
certificate occasionally needs to be used in a constrained environment =
and the
fact that the base standard that we are updating (RFC 3709) simply does =
not
allow embedded images.<br>
<br>
One way to do this could be to store images in a separate extension and =
then
define &nbsp;a way to reference that image from the logotype extension =
through
an internal reference.<br>
<br>
My proposed resolution is to exclude local storage from the current =
draft.<br>
Defining local embedding is adding unnecessary complexity to the =
draft.<br>
<br>
If a strong reason emerges to allow local storage, then this can be =
defined in
a separate draft.<br>
<br>
/Stefan </span></font><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_003D_01CA0A1E.367BCC60--

Date: Tue, 21 Jul 2009 11:57:41 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3331022266_5038418
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

I=B9m sorry Anders, but totally fail to see how this has anything to do with
the discussed issue.

I don=B9t see any =B3competing proposal=B2
Is there any chance you could give me a distinct short explanation in one
sentence or two that would help me understand.

/Stefan

On 09-07-21 11:10 AM, "Anders Rundgren" <[email-masked]> wrote:

>=20
>=20
>=20
>=20
>=20
> finally is here while interoperable and generally available authenticatio=
n
>=20
>=20
>> =20
>>=20
>> obtained it, creating the situation where the image is locally stored bu=
t
>>=20
>>=20
>>=20
>>=20
>>=20
>>  =20
>> =20
>>> =20
>>>=20
>>>=20
>>>    =20
>>> =20
>>>> =20
>>>> This is the first of two unresolved issues listed in the Certimage dra=
ft.
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>>=20
>>>> My proposed resolution is to exclude local storage from the current dr=
aft.
>>>> Defining local embedding is adding unnecessary complexity to the draft=
.
>>>>=20
>>>>=20
>>>> /Stefan=20
>>>>      =20
>>>> =20
>>> =20
>> =20
>>=20
>>=20
>>=20
>>  =20
>=20
>=20

--B_3331022266_5038418
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I&#8217;m sorry Anders, but totally fail to see how this has anything to d=
o with the discussed issue.<BR>
<BR>
I don&#8217;t see any &#8220;competing proposal&#8221;<BR>
Is there any chance you could give me a distinct short explanation in one s=
entence or two that would help me understand.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-07-21 11:10 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundg=
[email-masked]">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>Stefan,<BR>
<BR>
&gt;I'm not sure what you mean by &quot;competing&quot; proposal<BR>
<BR>
If you look back a few months on my comments to the cert-image I-D<BR>
you'll find pointers to an entirely different proposal which is built<BR>
on top of a new provisioning protocol which in turn builds on a<BR>
revised TPM-based key storage scheme:<BR>
<a href=3D"http://webpki.org/papers/keygen2/secure-key-store.pdf">http://webp=
ki.org/papers/keygen2/secure-key-store.pdf</a><BR>
<BR>
The &quot;humble&quot; goal is unifying Information Cards, PKI, and OTP bec=
ause<BR>
they are all useful but support quite distinct use-cases.<BR>
<BR>
Isn't this incredibly difficult to succeed with? &nbsp;Probably, but there =
is<BR>
no competition at least, since most people appear awfully busy solving<BR>
yesterdays' problems (like PKI middleware), ignoring higher-level aspects<B=
R>
of tokens such as utility in the real world where you need to deal with<BR>
multiple identities and technologies.<BR>
<BR>
In addition, &quot;iPhone &amp; friends&quot; have shown that the Mobile In=
ternet<BR>
finally is here while interoperable and generally available authentication<=
BR>
solutions are not. &nbsp;&nbsp;The described solution is also designed to f=
ill this vacuum.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote: <BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
Anders,<BR>
<BR>
I'm not sure what you mean by &quot;competing&quot; proposal, but a reasona=
ble<BR>
behavior by the client is to cache the certificate image once it has<BR>
obtained it, creating the situation where the image is locally stored but<B=
R>
not embedded.<BR>
<BR>
But you won't get away from that first retrieval.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-21 8:33 AM, &quot;Anders Rundgren&quot; &lt;<a href=3D"anders.rundgr=
[email-masked]">[email-masked]</a>&gt; &lt;<a href=3D"mailto:anders.r=
[email-masked]">mailto:[email-masked]</a>&gt; &nbsp;wrote:<BR>
<BR>
&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
In the &quot;competing&quot; proposal, certificate images are locally store=
d<BR>
but not embedded in certificates. &nbsp;This is a viable solution when<BR>
images are only to be consumed by the end-user. &nbsp;For external<BR>
consumption (which I consider an entirely different use-case),<BR>
the existing I-D seems quite sufficient.<BR>
<BR>
Anders<BR>
<BR>
Stefan Santesson wrote:<BR>
&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'> <BR>
This is the first of two unresolved issues listed in the Certimage draft.<B=
R>
<BR>
Is there any reason to provide any means to embed certificate images<BR>
in a certificate.<BR>
<BR>
The reason why this might be a valid option is because we often use<BR>
certificates in environments that have sufficient bandwidth and memory<BR>
capacity to allow certificate images to be stored in the certificate<BR>
itself. By storing the image in the certificate, we could save a<BR>
network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage<BR>
if a certificate occasionally needs to be used in a constrained<BR>
environment and the fact that the base standard that we are updating<BR>
(RFC 3709) simply does not allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension<BR>
and then define &nbsp;a way to reference that image from the logotype<BR>
extension through an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be<BR>
defined in a separate draft.<BR>
<BR>
/Stefan <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'> <BR>
<BR>
<BR>
<BR>
&nbsp;&nbsp;<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial">=
<SPAN STYLE=3D'font-size:11pt'><BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3331022266_5038418--

Date: Tue, 21 Jul 2009 11:10:44 +0200
From: Anders Rundgren <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------030507010909040806050708
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Stefan,

Anders

>>> defined in a separate draft.

--------------030507010909040806050708
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Stefan,<br>
<br>
&gt;I'm not sure what you mean by "competing" proposal<br>
<br>
If you look back a few months on my comments to the cert-image I-D<br>
you'll find pointers to an entirely different proposal which is built<br>
on top of a new provisioning protocol which in turn builds on a<br>
revised TPM-based key storage scheme:<br>
<a class="moz-txt-link-freetext"
 href="http://webpki.org/papers/keygen2/secure-key-store.pdf">http://webpki.org/papers/keygen2/secure-key-store.pdf</a><br>
<br>
The "humble" goal is unifying Information Cards, PKI, and OTP because<br>
they are all useful but support quite distinct use-cases.<br>
<br>
Isn't this incredibly difficult to succeed with?&nbsp; Probably, but there is<br>
no competition at least, since most people appear awfully busy solving<br>
yesterdays' problems (like PKI middleware), ignoring higher-level
aspects<br>
of tokens such as utility in the real world where you need to deal with<br>
multiple identities and technologies.<br>
<br>
In addition, "iPhone &amp; friends" have shown that the Mobile Internet<br>
finally is here while interoperable and generally available
authentication<br>
solutions are not. &nbsp; The described solution is also designed to fill
this vacuum.<br>
<br>
Anders<br>
<br>
Stefan Santesson wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">Anders,

/Stefan

On 09-07-21 8:33 AM, "Anders Rundgren" <a class="moz-txt-link-rfc2396E"
 href="mailto:[email-masked]">&lt;[email-masked]&gt;</a> wrote:

  </pre>
  <blockquote type="cite">
    <pre wrap="">In the "competing" proposal, certificate images are locally stored

Anders

Stefan Santesson wrote:
    </pre>
    <blockquote type="cite">
      <pre wrap="">This is the first of two unresolved issues listed in the Certimage draft.

/Stefan 
      </pre>
    </blockquote>
  </blockquote>
  <pre wrap=""><!---->

  </pre>
</blockquote>
<br>
</body>
</html>

--------------030507010909040806050708--

Date: Tue, 21 Jul 2009 08:54:05 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Anders Rundgren <[email-masked]>
CC: ietf-pkix <[email-masked]>
Sender: [email-masked]

Anders,

/Stefan

>> defined in a separate draft.

Date: Tue, 21 Jul 2009 08:33:29 +0200
From: Anders Rundgren <[email-masked]>
To: Stefan Santesson <[email-masked]>
CC: ietf-pkix <[email-masked]>
Subject: Re: Embedded certificate image
Sender: [email-masked]

Anders

> defined in a separate draft.

Date: Mon, 20 Jul 2009 23:43:10 +0200
Subject: Re: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: Thomas Hardjono <[email-masked]>, "'ietf-pkix'" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3330978192_3700881
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Hi Thomas,

When discussing the particular issue at hand, it has just been considered i=
n
relation to certificate images.
However I agree that if we would create such extension, that we should make
it generic.

/Stefan

On 09-07-20 10:44 PM, "Thomas Hardjono" <[email-masked]> wrote:

> Stefan,
> =20
> Has there been any thought about making such an extension =B3generic=B2 enoug=
h
> that it could reference other human-friendly objects (e.g. InfoCard, Open=
ID
> identity, etc. etc).
> =20
> /thomas/
> =20
> =20
> =20
>=20
> From: [email-masked] [mailto:[email-masked]] =
On
> =20
>=20
>=20
> capacity to allow certificate images to be stored in the certificate itse=
lf.
> By storing the image in the certificate, we could save a network retrieva=
l.
>=20
> certificate occasionally needs to be used in a constrained environment an=
d the
> fact that the base standard that we are updating (RFC 3709) simply does n=
ot
> allow embedded images.
>=20
> One way to do this could be to store images in a separate extension and t=
hen
> define  a way to reference that image from the logotype extension through=
 an
> internal reference.
>=20
> My proposed resolution is to exclude local storage from the current draft=
.
>=20
> If a strong reason emerges to allow local storage, then this can be defin=
ed in
>=20
> /Stefan=20
>=20

--B_3330978192_3700881
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Hi Thomas,<BR>
<BR>
When discussing the particular issue at hand, it has just been considered i=
n relation to certificate images.<BR>
However I agree that if we would create such extension, that we should make=
 it generic.<BR>
<BR>
I think that is yet another good argument that such extension should be sep=
arated from the certimage work.<BR>
<BR>
What is your assessment on the actual need to store objects like an informa=
tion card inside a certificate?<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-20 10:44 PM, &quot;Thomas Hardjono&quot; &lt;<a href=3D"ietf@hardjon=
o.net">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><SPAN STYLE=3D'font-size:11pt'><FONT COLOR=3D"#1F497D=
"><FONT FACE=3D"Courier New">Stefan,<BR>
&nbsp;<BR>
Has there been any thought about making such an extension &#8220;generic&#8=
221; enough that it could reference other human-friendly objects (e.g. InfoC=
ard, OpenID identity, etc. etc).<BR>
&nbsp;<BR>
/thomas/<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><BR>
</FONT></SPAN><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'><B>From:</B> <a href=3D"[email-masked]=
.org">[email-masked]</a> [<a href=3D"mailto:owner-ietf-pkix@mail=
.imc.org">mailto:[email-masked]</a>] <B>On Behalf Of </B>Stefa=
n Santesson<BR>
<B>Sent:</B> Monday, July 20, 2009 1:50 PM<BR>
<B>To:</B> ietf-pkix<BR>
<B>Subject:</B> Embedded certificate image<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>This is the first of two unresolved issues listed in the Cer=
timage draft.<BR>
<BR>
Is there any reason to provide any means to embed certificate images in a c=
ertificate.<BR>
<BR>
The reason why this might be a valid option is because we often use certifi=
cates in environments that have sufficient bandwidth and memory capacity to =
allow certificate images to be stored in the certificate itself. By storing =
the image in the certificate, we could save a network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage if a c=
ertificate occasionally needs to be used in a constrained environment and th=
e fact that the base standard that we are updating (RFC 3709) simply does no=
t allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension and the=
n define &nbsp;a way to reference that image from the logotype extension thr=
ough an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be defined=
 in a separate draft.<BR>
<BR>
/Stefan <BR>
<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3330978192_3700881--

From: "Thomas Hardjono" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, "'ietf-pkix'" <[email-masked]>
Subject: RE: Embedded certificate image
Date: Mon, 20 Jul 2009 16:44:04 -0400
Sender: [email-masked]

This is a multipart message in MIME format.

------=_NextPart_000_0076_01CA0959.500FC2F0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Stefan,

/thomas/

 

/Stefan 

------=_NextPart_000_0076_01CA0959.500FC2F0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

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

<head>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">

<meta name=3DProgId content=3DWord.Document>
<meta name=3DGenerator content=3D"Microsoft Word 12">
<meta name=3DOriginator content=3D"Microsoft Word 12">
<link rel=3DFile-List href=3D"cid:[email-masked]">
<title>Embedded certificate image</title>
<!--[if gte mso 9]><xml>
 <o:OfficeDocumentSettings>
  <o:AllowPNG/>
  <o:DoNotRelyOnCSS/>
  <o:TargetScreenSize>1024x768</o:TargetScreenSize>
 </o:OfficeDocumentSettings>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:WordDocument>
  <w:SpellingState>Clean</w:SpellingState>
  <w:TrackMoves/>
  <w:TrackFormatting/>
  <w:EnvelopeVis/>
  <w:ValidateAgainstSchemas/>
  <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid>
  <w:IgnoreMixedContent>false</w:IgnoreMixedContent>
  <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText>
  <w:DoNotPromoteQF/>
  <w:LidThemeOther>EN-US</w:LidThemeOther>
  <w:LidThemeAsian>X-NONE</w:LidThemeAsian>
  <w:LidThemeComplexScript>X-NONE</w:LidThemeComplexScript>
  <w:Compatibility>
   <w:DoNotExpandShiftReturn/>
   <w:BreakWrappedTables/>
   <w:SplitPgBreakAndParaMark/>
   <w:DontVertAlignCellWithSp/>
   <w:DontBreakConstrainedForcedTables/>
   <w:DontVertAlignInTxbx/>
   <w:Word11KerningPairs/>
   <w:CachedColBalance/>
  </w:Compatibility>
  <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel>
  <m:mathPr>
   <m:mathFont m:val=3D"Cambria Math"/>
   <m:brkBin m:val=3D"before"/>
   <m:brkBinSub m:val=3D"--"/>
   <m:smallFrac m:val=3D"off"/>
   <m:dispDef/>
   <m:lMargin m:val=3D"0"/>
   <m:rMargin m:val=3D"0"/>
   <m:defJc m:val=3D"centerGroup"/>
   <m:wrapIndent m:val=3D"1440"/>
   <m:intLim m:val=3D"subSup"/>
   <m:naryLim m:val=3D"undOvr"/>
  </m:mathPr></w:WordDocument>
</xml><![endif]--><!--[if gte mso 9]><xml>
 <w:LatentStyles DefLockedState=3D"false" DefUnhideWhenUsed=3D"true"=20
  DefSemiHidden=3D"true" DefQFormat=3D"false" DefPriority=3D"99"=20
  LatentStyleCount=3D"267">
  <w:LsdException Locked=3D"false" Priority=3D"0" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Normal"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"heading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"9" QFormat=3D"true" =
Name=3D"heading 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 7"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 8"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" Name=3D"toc 9"/>
  <w:LsdException Locked=3D"false" Priority=3D"35" QFormat=3D"true" =
Name=3D"caption"/>
  <w:LsdException Locked=3D"false" Priority=3D"10" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" Name=3D"Default =
Paragraph Font"/>
  <w:LsdException Locked=3D"false" Priority=3D"11" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtitle"/>
  <w:LsdException Locked=3D"false" Priority=3D"22" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Strong"/>
  <w:LsdException Locked=3D"false" Priority=3D"20" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"59" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Table Grid"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Placeholder Text"/>
  <w:LsdException Locked=3D"false" Priority=3D"1" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"No Spacing"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 1"/>
  <w:LsdException Locked=3D"false" UnhideWhenUsed=3D"false" =
Name=3D"Revision"/>
  <w:LsdException Locked=3D"false" Priority=3D"34" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"List Paragraph"/>
  <w:LsdException Locked=3D"false" Priority=3D"29" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"30" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Quote"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 1"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 2"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 3"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 4"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 5"/>
  <w:LsdException Locked=3D"false" Priority=3D"60" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"61" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"62" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Light Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"63" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"64" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Shading 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"65" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"66" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium List 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"67" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 1 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"68" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 2 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"69" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Medium Grid 3 Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"70" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Dark List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"71" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Shading Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"72" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful List Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"73" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" Name=3D"Colorful Grid Accent 6"/>
  <w:LsdException Locked=3D"false" Priority=3D"19" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"21" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense Emphasis"/>
  <w:LsdException Locked=3D"false" Priority=3D"31" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Subtle Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"32" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Intense =
Reference"/>
  <w:LsdException Locked=3D"false" Priority=3D"33" SemiHidden=3D"false"=20
   UnhideWhenUsed=3D"false" QFormat=3D"true" Name=3D"Book Title"/>
  <w:LsdException Locked=3D"false" Priority=3D"37" =
Name=3D"Bibliography"/>
  <w:LsdException Locked=3D"false" Priority=3D"39" QFormat=3D"true" =
Name=3D"TOC Heading"/>
 </w:LatentStyles>
</xml><![endif]-->
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:-1610611985 1073750139 0 0 159 0;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;
	mso-font-charset:0;
	mso-generic-font-family:swiss;
	mso-font-pitch:variable;
	mso-font-signature:1627400839 -2147483648 8 0 66047 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{mso-style-unhide:no;
	mso-style-qformat:yes;
	mso-style-parent:"";
	margin:0in;
	margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";
	mso-fareast-font-family:Calibri;}
a:link, span.MsoHyperlink
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:blue;
	text-decoration:underline;
	text-underline:single;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-noshow:yes;
	mso-style-priority:99;
	color:purple;
	text-decoration:underline;
	text-underline:single;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	mso-style-noshow:yes;
	mso-style-unhide:no;
	mso-ansi-font-size:11.0pt;
	mso-bidi-font-size:11.0pt;
	font-family:"Courier New";
	mso-ascii-font-family:"Courier New";
	mso-hansi-font-family:"Courier New";
	mso-bidi-font-family:"Times New Roman";
	color:#1F497D;}
span.SpellE
	{mso-style-name:"";
	mso-spl-e:yes;}
.MsoChpDefault
	{mso-style-type:export-only;
	mso-default-props:yes;
	font-size:10.0pt;
	mso-ansi-font-size:10.0pt;
	mso-bidi-font-size:10.0pt;}
@page Section1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;
	mso-header-margin:.5in;
	mso-footer-margin:.5in;
	mso-paper-source:0;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 10]>
<style>
 /* Style Definitions */=20
 table.MsoNormalTable
	{mso-style-name:"Table Normal";
	mso-tstyle-rowband-size:0;
	mso-tstyle-colband-size:0;
	mso-style-noshow:yes;
	mso-style-priority:99;
	mso-style-qformat:yes;
	mso-style-parent:"";
	mso-padding-alt:0in 5.4pt 0in 5.4pt;
	mso-para-margin:0in;
	mso-para-margin-bottom:.0001pt;
	mso-pagination:widow-orphan;
	font-size:10.0pt;
	font-family:"Times New Roman","serif";}
</style>
<![endif]--><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-US link=3Dblue vlink=3Dpurple =
style=3D'tab-interval:.5in'>

<div class=3DSection1>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>Stefan,<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>Has there been any thought about making such an extension =
&#8220;generic&#8221;
enough that it could reference other human-friendly objects (e.g. <span
class=3DSpellE>InfoCard</span>, <span class=3DSpellE>OpenID</span> =
identity, etc.
etc).<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'>/thomas/<o:p></o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

<p class=3DMsoNormal><font size=3D2 color=3D"#1f497d" face=3D"Courier =
New"><span
style=3D'font-size:11.0pt;font-family:"Courier =
New";mso-bidi-font-family:"Times New Roman";
color:#1F497D'><o:p>&nbsp;</o:p></span></font></p>

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

<div>

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

<p class=3DMsoNormal><b><font size=3D2 face=3DTahoma><span =
style=3D'font-size:10.0pt;
font-family:"Tahoma","sans-serif";mso-fareast-font-family:"Times New =
Roman";
font-weight:bold'>From:</span></font></b><font size=3D2 =
face=3DTahoma><span
style=3D'font-size:10.0pt;font-family:"Tahoma","sans-serif";mso-fareast-f=
ont-family:
"Times New Roman"'> [email-masked]
[mailto:[email-masked]] <b><span =
style=3D'font-weight:bold'>On
Behalf Of </span></b>Stefan Santesson<br>
<b><span style=3D'font-weight:bold'>Sent:</span></b> Monday, July 20, =
2009 1:50
PM<br>
<b><span style=3D'font-weight:bold'>To:</span></b> ietf-pkix<br>
<b><span style=3D'font-weight:bold'>Subject:</span></b> Embedded =
certificate
image<o:p></o:p></span></font></p>

</div>

</div>

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

<p class=3DMsoNormal><font size=3D2 face=3DCalibri><span =
style=3D'font-size:11.0pt;
font-family:"Calibri","sans-serif";mso-fareast-font-family:"Times New =
Roman"'>This
is the first of two unresolved issues listed in the Certimage draft.<br>
<br>
Is there any reason to provide any means to embed certificate images in =
a
certificate.<br>
<br>
The reason why this might be a valid option is because we often use
certificates in environments that have sufficient bandwidth and memory =
capacity
to allow certificate images to be stored in the certificate itself. By =
storing
the image in the certificate, we could save a network retrieval.<br>
<br>
The main counter argument is that it would be a serious disadvantage if =
a
certificate occasionally needs to be used in a constrained environment =
and the
fact that the base standard that we are updating (RFC 3709) simply does =
not
allow embedded images.<br>
<br>
One way to do this could be to store images in a separate extension and =
then
define &nbsp;a way to reference that image from the logotype extension =
through
an internal reference.<br>
<br>
My proposed resolution is to exclude local storage from the current =
draft.<br>
Defining local embedding is adding unnecessary complexity to the =
draft.<br>
<br>
If a strong reason emerges to allow local storage, then this can be =
defined in
a separate draft.<br>
<br>
/Stefan </span></font><span style=3D'mso-fareast-font-family:"Times New =
Roman"'><o:p></o:p></span></p>

</div>

</div>

</body>

</html>

------=_NextPart_000_0076_01CA0959.500FC2F0--

Date: Mon, 20 Jul 2009 19:49:36 +0200
Subject: Embedded certificate image
From: Stefan Santesson <[email-masked]>
To: ietf-pkix <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3330964180_2850767
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

/Stefan 

--B_3330964180_2850767
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Embedded certificate image</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>This is the first of two unresolved issues listed in the Certimage draft.<=
BR>
<BR>
Is there any reason to provide any means to embed certificate images in a c=
ertificate.<BR>
<BR>
The reason why this might be a valid option is because we often use certifi=
cates in environments that have sufficient bandwidth and memory capacity to =
allow certificate images to be stored in the certificate itself. By storing =
the image in the certificate, we could save a network retrieval.<BR>
<BR>
The main counter argument is that it would be a serious disadvantage if a c=
ertificate occasionally needs to be used in a constrained environment and th=
e fact that the base standard that we are updating (RFC 3709) simply does no=
t allow embedded images.<BR>
<BR>
One way to do this could be to store images in a separate extension and the=
n define &nbsp;a way to reference that image from the logotype extension thr=
ough an internal reference.<BR>
<BR>
My proposed resolution is to exclude local storage from the current draft.<=
BR>
Defining local embedding is adding unnecessary complexity to the draft.<BR>
<BR>
If a strong reason emerges to allow local storage, then this can be defined=
 in a separate draft.<BR>
<BR>
/Stefan </SPAN></FONT>
</BODY>
</HTML>

--B_3330964180_2850767--

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Date: Mon, 20 Jul 2009 22:56:23 +1200
Sender: [email-masked]

>Peter,
>
>Could you then give me the "sales pitch on a T-shirt" version of this.
>
>I'm reading the PK Superstructure document and can only find philosophical
>differences but no technical ones, except for a critical extension which
>meaning and purpose is unclear to me.

Uhh, I think that was meant for Stephen, not me...

Peter.

Date: Mon, 20 Jul 2009 12:55:18 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility'
From: Stefan Santesson <[email-masked]>
To: Stephen Wilson <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Hi Stephen,

On 09-07-20 12:06 PM, "Stephen Wilson" <[email-masked]> wrote:

> 
> 
> Stefan Santesson wrote:
>> Stephen,
>> 
>> Sorry for bringing a negative touch, but I think your mails looks more like
>> sales pitch for your company's business agenda than creative proposal on PKI
>> protocol development.
> I don't mind criticism but that's unwarranted.  I have no commercial
> interest in any of this.  And I have no agenda other than to promote
> better, fresher applications of PKI.  We all know that PKI is
> misunderstood and feared for its complexity, but it's less appreciated
> that the complexity is mostly of our  making.

Your initial mail contained quite some advertising and made that impression
on me. I'll accept the assumption that you are acting for the good of man
kind. ;)

>> You may implement whatever model of administration around certificates and
>> their issuance as you like. They are still signed by the CA's key which
>> makes them a statement by the CA.
> You're reflecting the arbitrary constructs of orthodox PKI.  The
> metaphors of "signature" and "statement" and the like have landed us in
> a situation where people cannot conceieve of other ways to construe what
> it is that a CA does.  What if rather than 'signing a statement by the
> CA', we imagine the CA as putting its seal on a certificate in order to
> render that tamper resistant, and to bind other authority information?

I don't understand the practical implication of your argument, other than
that you like to use other words.

>> Unlike cheques, certificates can't have information added to the after
>> issuance/signing. That does not mean that the CA have to accept any liability
>> for their use.
> It's not the liability for (mis)use that concerns me here, it's the
> liability for registration errors.

The CA is not required by technology or protocols to accept any liability.
The certificate will still be issued by the CA and thus be a statement by
the CA.

>> 
>> Finally, I'm even more puzzled when a company claiming to be in the security
>> business, suggests other security expert to download their whitepapers, that
>> turns out to be an .exe file.
> It wasn't an .exe, it was just a link to a page.

Yeah, noticed, But it still downloads as an .exe on a Mac. I think that is
worth fixing :) It could be sorted by linking directly to the .pdf file.

> 
> BTW I am not trying to introduce any new "protocols" here and I haven't
> offered these thoughts for any technical consideration by the PKIX WG.
> Just trying to show that certain conventions of old PKI (like the idea
> that the CA "is ultimately the responsible party") might be arbitrary
> and useful to review.  These ideas were rather well received at the
> IDtrust conference in 2008.
> 
> Cheers,
> 
> Stephen.

Great. In the sense that this might effect how we develop protocols for PKI,
the discussion is valid. But I'm afraid that I just have a hard time to
understand the core of you ideas.

What I read in your paper is that you more or less want the RA to be the
issuer and the CA to be the facilitator for issuing certificate, but with no
liability for any faults committed by the RA, just for the operation of the
CA "factory".

Now, it is problematic in the sense that the RA, who in such case acts as
issuer, is not identified in the certificate. Unless the RA is identified as
issuer, the certificate is by definition a statement by the CA.

If you OTOH identify the RA as the issuer, then you have just made the RA a
CA and turned the CA into a facility operator, which is a model that has
been in existence for a long time.

If you try to do this by allowing the CA to use a common issuing key for
many RAs identified as issuers, then we have created a mess and violated a
whole bunch of standards..

Basically, I don't see the real difference from current PKI with limited
liability. Feel free to correct my misguided mind..

/Stefan

Date: Mon, 20 Jul 2009 12:17:29 +0200
Subject: Re: RFC5280 : Applications and CRL DP extension support
From: Stefan Santesson <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Jean,

CRLDP is not required in that meaning, but matching distribution points is
an extra feature to ensure that you are actually using the right CRL.

The basic assumption for PKI is that CA names are selected in a way that
you will not trust several CAs with identical names at the same time.
Following that assumption it is sufficient to match the name of the
certificate issuer in the certificate and the CRL.

In the absence of an IDP, the CRL must have a complete scope, and most CRLs
are issued with a complete scope.

However, It was once a disjoint in the way Microsoft issued its CRLs that
they allowed CRLs to cover "only" certificates issued under one CA key
without including IDP in the CRL, even if that CA under the same name had
issued certificates with another key. They had to add an IDP to the CRLs to
allow that limited scope. In this case the matching of distribution points
helps identifying the scope of the CRL by ensuring that you are looking at
the intended CRL for the certificate you are validating.

So it is logical to me that CDP is recommended to support CRL discovery, but
allowing IDP to be optional as long as the CRL has a complete scope.

/Stefan 

On 09-07-20 11:54 AM, "Jean-Marc Desperrier" <[email-masked]> wrote:

> 
> Stefan Santesson wrote:
>> When a CRLDP is present in a certificate and an Issuing Distribution point
>> extension is present in the CRL, them the distribution points of these
>> extensions MUST match as defined in section 5.2.5 of RFC 5280.
> 
> Yes, of course, but if support of CRLDP is only really required in that
> meaning, then there's a mismatch between the fact that application
> support of CRLDP is recommended, but support of IDP is optional (given
> that IDP  MUST be critical):
> 
>     4.2.1.13.  CRL Distribution Points
>     [...] this profile
>     RECOMMENDS support for this extension by CAs and applications.
> 
>     5.2.5.  Issuing Distribution Point
>     [...] conforming implementations are not required to support
>     this extension
> 
> Maybe the RECOMMENDS for CRL DP should best be read as meaning that the
> application SHOULD be able to parse and make the info available to the
> user ?
> 

Date: Mon, 20 Jul 2009 20:06:50 +1000
From: Stephen Wilson <[email-masked]>
To: [email-masked]
Subject: Re: Relieving CAs of 'ultimate responsibility'
Sender: [email-masked]

Stefan Santesson wrote:
> Stephen,
>
> Sorry for bringing a negative touch, but I think your mails looks more like sales pitch for your company's business agenda than creative proposal on PKI protocol development.
I don't mind criticism but that's unwarranted.  I have no commercial 
interest in any of this.  And I have no agenda other than to promote 
better, fresher applications of PKI.  We all know that PKI is 
misunderstood and feared for its complexity, but it's less appreciated 
that the complexity is mostly of our  making. 
> You may implement whatever model of administration around certificates and
> their issuance as you like. They are still signed by the CA's key which
> makes them a statement by the CA. 
You're reflecting the arbitrary constructs of orthodox PKI.  The 
metaphors of "signature" and "statement" and the like have landed us in 
a situation where people cannot conceieve of other ways to construe what 
it is that a CA does.  What if rather than 'signing a statement by the 
CA', we imagine the CA as putting its seal on a certificate in order to 
render that tamper resistant, and to bind other authority information? 
> Unlike cheques, certificates can't have information added to the after issuance/signing. That does not mean that the CA have to accept any liability for their use.
It's not the liability for (mis)use that concerns me here, it's the 
liability for registration errors.
>
> Finally, I'm even more puzzled when a company claiming to be in the security business, suggests other security expert to download their whitepapers, that turns out to be an .exe file.
It wasn't an .exe, it was just a link to a page. 

BTW I am not trying to introduce any new "protocols" here and I haven't 
offered these thoughts for any technical consideration by the PKIX WG.  
Just trying to show that certain conventions of old PKI (like the idea 
that the CA "is ultimately the responsible party") might be arbitrary 
and useful to review.  These ideas were rather well received at the 
IDtrust conference in 2008.

Cheers,

Stephen.

Stephen Wilson
Lockstep
www.lockstep.com.au

>
> Peter Gutmann wrote:
>>> Stephen Wilson <[email-masked]> writes:
>>>> But there is a way to relieve CAs of many risks, and at the same time
>>>> simplify the legal principles, the user agreements and the PKI business
>>>> model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>>> should only be responsible for the quality of the certificates (cheques) but
>>>> not their content.
>>>>
>>>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>>> Hmm, interesting perspective.  However, if this is implemented, can I put
>>> down my name to be the certificate vending machine?  Someone else (handwave)
>>> can be the RA.
>>>
>>> Peter.
>> I think the sarcasm is misplaced.
>>
>> Running a CA or a cheque printer is tougher than running a vending
>> machine.  The Security Printer model still requires a multi million
>> dollar investment in facilities security, Commion Criteria certified
>> systems, trusted personnel and so on.  And it's not a licence to print
>> money -- these should be high volume, low margin businesses.  I was
>> asked a question from the audience at an Asia PKI Forum conference once
>> how many CAs I thought were needed in the world, and I said "about three
>> or four".
>>
>> Picking RAs is not a hand waving exercise.  In most cases, the choice of
>> RA is logical and transparent: medical registration boards, licensing
>> bodies, employers, professional associations etc.
>>
>> This view of PKI holds that digital cerificates are best used to
>> automate transactions between parties that already recognise one
>> anothers' qualifications (and who therefore already have risk mitigation
>> arrangements in place, like professional indemnity schemes).  Therefore
>> certificates should be issued by existing credentialling authorities
>> (the RAs), and minted by specialist wholesale CAs.  There are other
>> precedents for this type of model, like bank card production.  We have
>> many many banks, issuing many many card products, but only a few large
>> scale card personalisation bureaus.
>>
>> In this way, the meaningfulness of certificates vests in existing
>> recognised bodies.  All the traditionally intractable problems of PKI
>> disappear (like certificate cross-recognition, because in commerce and
>> the professions we have ways of recognising credentials issued by
>> cross-border RAs).
>>
>> See also http://www.lockstep.com.au/library/pki/public_key_superstructure
>>
>> To move to the Security Printer paradigm requires we give up a few of
>> the long standing PKI ambitions, like the dream of stranger-to-stranger
>> e-commerce, and the dream of a one-size-fits-all multipurpose digital
>> certificate. 
>>
>> Cheers,
>>
>> Stephen Wilson
>> Lockstep
>> www.lockstep.com.au
>>
>
>
>
>

Date: Mon, 20 Jul 2009 11:54:27 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: Re: RFC5280 : Applications and CRL DP extension support
Sender: [email-masked]

Stefan Santesson wrote:
> When a CRLDP is present in a certificate and an Issuing Distribution point
> extension is present in the CRL, them the distribution points of these
> extensions MUST match as defined in section 5.2.5 of RFC 5280.

Yes, of course, but if support of CRLDP is only really required in that 
meaning, then there's a mismatch between the fact that application 
support of CRLDP is recommended, but support of IDP is optional (given 
that IDP  MUST be critical):

    4.2.1.13.  CRL Distribution Points
    [...] this profile
    RECOMMENDS support for this extension by CAs and applications.

    5.2.5.  Issuing Distribution Point
    [...] conforming implementations are not required to support
    this extension

Maybe the RECOMMENDS for CRL DP should best be read as meaning that the 
application SHOULD be able to parse and make the info available to the 
user ?

Date: Mon, 20 Jul 2009 11:07:10 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
From: Stefan Santesson <[email-masked]>
To: Peter Gutmann <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Peter,

Could you then give me the "sales pitch on a T-shirt" version of this.

I'm reading the PK Superstructure document and can only find philosophical
differences but no technical ones, except for a critical extension which
meaning and purpose is unclear to me.

/Stefan

On 09-07-20 10:54 AM, "Peter Gutmann" <[email-masked]> wrote:

>> Stephen is right, it really is much like passports or cheques. There's all
>> sorts of security considerations about printing them, but the hard part is
>> the government or banks deciding to actually take the responsibility for the
>> issuing process.
> 
> Yup, that's what I was trying to point out, everyone wants to be the CA and
> collect the money, no-one wants to take responsibility (except in closed
> communities where you internalise the risk, and then have the luxury of being
> able to run things any way you like because of it).
> 
> Peter.
> 

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: RE: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Date: Mon, 20 Jul 2009 20:54:29 +1200
Sender: [email-masked]

Yoav Nir <[email-masked]> writes:

>Stephen is right, it really is much like passports or cheques. There's all
>sorts of security considerations about printing them, but the hard part is
>the government or banks deciding to actually take the responsibility for the
>issuing process.

Yup, that's what I was trying to point out, everyone wants to be the CA and
collect the money, no-one wants to take responsibility (except in closed
communities where you internalise the risk, and then have the luxury of being
able to run things any way you like because of it).

Peter.

Date: Mon, 20 Jul 2009 10:26:37 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility' 
From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, Stephen Wilson <[email-masked]>, <[email-masked]>
Sender: [email-masked]

My apologies for the .exe file comment.
At a closer look it appears to be a legal pdf, but the way you link to your
documents seems a bit odd as the link doesn't reveal the file type at all.

When clicking the link from a Mac OS using safari, it downloads as an .exe
file which isn't very nice. You should look into that.

/Stefan

On 09-07-20 9:14 AM, "Stefan Santesson" <[email-masked]> wrote:

> 
> Stephen,
> 
> Sorry for bringing a negative touch, but I think your mails looks more like
> sales pitch for your company's business agenda than creative proposal on PKI
> protocol development.
> 
> You may implement whatever model of administration around certificates and
> their issuance as you like. They are still signed by the CA's key which
> makes them a statement by the CA. Unlike cheques, certificates can't have
> information added to the after issuance/signing.That does not mean that the
> CA have to accept any liability for their use.
> 
> Finally, I'm even more puzzled when a company claiming to be in the security
> business, suggests other security expert to download their whitepapers, that
> turns out to be an .exe file.
> 
> Whatever it is, it will not execute on my computer.
> 
> /Stefan
> 
> 
> On 09-07-20 4:45 AM, "Stephen Wilson" <[email-masked]> wrote:
> 
>> 
>> 
>> 
>> Peter Gutmann wrote:
>>> Stephen Wilson <[email-masked]> writes:
>>>> But there is a way to relieve CAs of many risks, and at the same time
>>>> simplify the legal principles, the user agreements and the PKI business
>>>> model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>>> should only be responsible for the quality of the certificates (cheques)
>>>> but
>>>> not their content.
>>>> 
>>>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>>> 
>>> Hmm, interesting perspective.  However, if this is implemented, can I put
>>> down my name to be the certificate vending machine?  Someone else (handwave)
>>> can be the RA.
>>> 
>>> Peter.
>> I think the sarcasm is misplaced.
>> 
>> Running a CA or a cheque printer is tougher than running a vending
>> machine.  The Security Printer model still requires a multi million
>> dollar investment in facilities security, Commion Criteria certified
>> systems, trusted personnel and so on.  And it's not a licence to print
>> money -- these should be high volume, low margin businesses.  I was
>> asked a question from the audience at an Asia PKI Forum conference once
>> how many CAs I thought were needed in the world, and I said "about three
>> or four".
>> 
>> Picking RAs is not a hand waving exercise.  In most cases, the choice of
>> RA is logical and transparent: medical registration boards, licensing
>> bodies, employers, professional associations etc.
>> 
>> This view of PKI holds that digital cerificates are best used to
>> automate transactions between parties that already recognise one
>> anothers' qualifications (and who therefore already have risk mitigation
>> arrangements in place, like professional indemnity schemes).  Therefore
>> certificates should be issued by existing credentialling authorities
>> (the RAs), and minted by specialist wholesale CAs.  There are other
>> precedents for this type of model, like bank card production.  We have
>> many many banks, issuing many many card products, but only a few large
>> scale card personalisation bureaus.
>> 
>> In this way, the meaningfulness of certificates vests in existing
>> recognised bodies.  All the traditionally intractable problems of PKI
>> disappear (like certificate cross-recognition, because in commerce and
>> the professions we have ways of recognising credentials issued by
>> cross-border RAs).
>> 
>> See also http://www.lockstep.com.au/library/pki/public_key_superstructure
>> 
>> To move to the Security Printer paradigm requires we give up a few of
>> the long standing PKI ambitions, like the dream of stranger-to-stranger
>> e-commerce, and the dream of a one-size-fits-all multipurpose digital
>> certificate. 
>> 
>> Cheers,
>> 
>> Stephen Wilson
>> Lockstep
>> www.lockstep.com.au
>> 
> 
> 

Date: Mon, 20 Jul 2009 09:14:15 +0200
Subject: Re: Relieving CAs of 'ultimate responsibility' 
From: Stefan Santesson <[email-masked]>
To: Stephen Wilson <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Stephen,

Sorry for bringing a negative touch, but I think your mails looks more like
sales pitch for your company's business agenda than creative proposal on PKI
protocol development.

You may implement whatever model of administration around certificates and
their issuance as you like. They are still signed by the CA's key which
makes them a statement by the CA. Unlike cheques, certificates can't have
information added to the after issuance/signing.That does not mean that the
CA have to accept any liability for their use.

Finally, I'm even more puzzled when a company claiming to be in the security
business, suggests other security expert to download their whitepapers, that
turns out to be an .exe file.

Whatever it is, it will not execute on my computer.

/Stefan

On 09-07-20 4:45 AM, "Stephen Wilson" <[email-masked]> wrote:

> 
> 
> 
> Peter Gutmann wrote:
>> Stephen Wilson <[email-masked]> writes:
>>> But there is a way to relieve CAs of many risks, and at the same time
>>> simplify the legal principles, the user agreements and the PKI business
>>> model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>> should only be responsible for the quality of the certificates (cheques) but
>>> not their content.
>>> 
>>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>> 
>> Hmm, interesting perspective.  However, if this is implemented, can I put
>> down my name to be the certificate vending machine?  Someone else (handwave)
>> can be the RA.
>> 
>> Peter.
> I think the sarcasm is misplaced.
> 
> Running a CA or a cheque printer is tougher than running a vending
> machine.  The Security Printer model still requires a multi million
> dollar investment in facilities security, Commion Criteria certified
> systems, trusted personnel and so on.  And it's not a licence to print
> money -- these should be high volume, low margin businesses.  I was
> asked a question from the audience at an Asia PKI Forum conference once
> how many CAs I thought were needed in the world, and I said "about three
> or four".
> 
> Picking RAs is not a hand waving exercise.  In most cases, the choice of
> RA is logical and transparent: medical registration boards, licensing
> bodies, employers, professional associations etc.
> 
> This view of PKI holds that digital cerificates are best used to
> automate transactions between parties that already recognise one
> anothers' qualifications (and who therefore already have risk mitigation
> arrangements in place, like professional indemnity schemes).  Therefore
> certificates should be issued by existing credentialling authorities
> (the RAs), and minted by specialist wholesale CAs.  There are other
> precedents for this type of model, like bank card production.  We have
> many many banks, issuing many many card products, but only a few large
> scale card personalisation bureaus.
> 
> In this way, the meaningfulness of certificates vests in existing
> recognised bodies.  All the traditionally intractable problems of PKI
> disappear (like certificate cross-recognition, because in commerce and
> the professions we have ways of recognising credentials issued by
> cross-border RAs).
> 
> See also http://www.lockstep.com.au/library/pki/public_key_superstructure
> 
> To move to the Security Printer paradigm requires we give up a few of
> the long standing PKI ambitions, like the dream of stranger-to-stranger
> e-commerce, and the dream of a one-size-fits-all multipurpose digital
> certificate. 
> 
> Cheers,
> 
> Stephen Wilson
> Lockstep
> www.lockstep.com.au
> 

From: Yoav Nir <[email-masked]>
To: "'Peter Gutmann'" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 20 Jul 2009 07:34:28 +0300
Subject: RE: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Accept-Language: en-US
acceptlanguage: en-US
Sender: [email-masked]

Peter Gutmann wrote:

>Stephen Wilson <[email-masked]> writes:
>
>>But there is a way to relieve CAs of many risks, and at the same time
>>simplify the legal principles, the user agreements and the PKI business
>>model: treat the CA like a Security Printer. Like a cheque printer, a CA
>>should only be responsible for the quality of the certificates (cheques) =
>but
>>not their content.
>>
>>See http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>
>Hmm, interesting perspective.  However, if this is implemented, can I put =
>down my name to be the certificate vending machine?  Someone else=20
>(handwave) can be
>the RA.
>

I think under that model, you end up with some kind of statutory authority =
to be the RA, so I guess those commercial certificates would come from some=
 ministry of industry, trade and silly walks, with the CA just providing a =
service under contract to the government.

This sounds great, but so far no government that I know of has taken it upo=
n itself to issue certificates to businesses, and few have done so for the =
citizens. If they had wanted to, then setting up a CA to actually sign blob=
s is cheap enough that it wouldn't be an issue.

Stephen is right, it really is much like passports or cheques. There's all =
sorts of security considerations about printing them, but the hard part is =
the government or banks deciding to actually take the responsibility for th=
e issuing process. I don't see that happening in the contexts discussed on =
PKIX.

Date: Mon, 20 Jul 2009 12:45:56 +1000
From: Stephen Wilson <[email-masked]>
To: [email-masked]
Subject: Re: Relieving CAs of 'ultimate responsibility' 
Sender: [email-masked]

Peter Gutmann wrote:
> Stephen Wilson <[email-masked]> writes:
>> But there is a way to relieve CAs of many risks, and at the same time
>> simplify the legal principles, the user agreements and the PKI business model: treat the CA like a Security Printer. Like a cheque printer, a CA should only be responsible for the quality of the certificates (cheques) but not their content.
>>
>> http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.
>
> Hmm, interesting perspective.  However, if this is implemented, can I put down my name to be the certificate vending machine?  Someone else (handwave) can be the RA.
>
> Peter.
I think the sarcasm is misplaced.

Running a CA or a cheque printer is tougher than running a vending 
machine.  The Security Printer model still requires a multi million 
dollar investment in facilities security, Commion Criteria certified 
systems, trusted personnel and so on.  And it's not a licence to print 
money -- these should be high volume, low margin businesses.  I was 
asked a question from the audience at an Asia PKI Forum conference once 
how many CAs I thought were needed in the world, and I said "about three 
or four".

Picking RAs is not a hand waving exercise.  In most cases, the choice of 
RA is logical and transparent: medical registration boards, licensing 
bodies, employers, professional associations etc.  

This view of PKI holds that digital cerificates are best used to 
automate transactions between parties that already recognise one 
anothers' qualifications (and who therefore already have risk mitigation 
arrangements in place, like professional indemnity schemes).  Therefore 
certificates should be issued by existing credentialling authorities 
(the RAs), and minted by specialist wholesale CAs.  There are other 
precedents for this type of model, like bank card production.  We have 
many many banks, issuing many many card products, but only a few large 
scale card personalisation bureaus.

In this way, the meaningfulness of certificates vests in existing 
recognised bodies.  All the traditionally intractable problems of PKI 
disappear (like certificate cross-recognition, because in commerce and 
the professions we have ways of recognising credentials issued by 
cross-border RAs).

See also http://www.lockstep.com.au/library/pki/public_key_superstructure

To move to the Security Printer paradigm requires we give up a few of 
the long standing PKI ambitions, like the dream of stranger-to-stranger 
e-commerce, and the dream of a one-size-fits-all multipurpose digital 
certificate. 

Cheers,

Stephen Wilson
Lockstep
www.lockstep.com.au

From: Peter Gutmann <[email-masked]>
To: [email-masked], [email-masked]
Subject: Re: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161]
Date: Mon, 20 Jul 2009 14:02:14 +1200
Sender: [email-masked]

Stephen Wilson <[email-masked]> writes:

>But there is a way to relieve CAs of many risks, and at the same time
>simplify the legal principles, the user agreements and the PKI business
>model: treat the CA like a Security Printer. Like a cheque printer, a CA
>should only be responsible for the quality of the certificates (cheques) but
>not their content.
>
>See http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.

Hmm, interesting perspective.  However, if this is implemented, can I put down
my name to be the certificate vending machine?  Someone else (handwave) can be
the RA.

Peter.

Date: Mon, 20 Jul 2009 01:20:16 +0200
Subject: Re: RFC5280 : Applications and CRL DP extension support
From: Stefan Santesson <[email-masked]>
To: Santosh Chokhani <[email-masked]>, Jean-Marc Desperrier <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Santosh,

Agreeing and I don't think our observations are in conflict.
You need to make sure both that you cover all relevant scopes as well as the
CRLs you are using matches the certificate you validate. I was only
addressing the latter.

/Stefan

On 09-07-19 5:24 PM, "Santosh Chokhani" <[email-masked]> wrote:

> Stefan,
> 
> The imprecision in the statement below can lead to security problem.  If
> IDP is present in a CRL with DP in the IDP, even if there is no CRL DP
> in the certificate, that CRL with DP in IDP can not be used by relying
> parties since whether the CRL covers the scope of the certificate or
> not, is unknown.
> 
>> Sent: Sunday, July 19, 2009 10:24 AM
>> To: Jean-Marc Desperrier; [email-masked]
>> Subject: Re: RFC5280 : Applications and CRL DP extension support
>> 
>> 
>> Jean,
>> 
>> An aspect of this often forgotten is that a major practical
>> function of the CRLDP is to act as an identifier used to
>> match the certificate and the CRL.
>> 
>> When a CRLDP is present in a certificate and an Issuing
>> Distribution point extension is present in the CRL, them the
>> distribution points of these extensions MUST match as defined
>> in section 5.2.5 of RFC 5280.
>> 
>> As far as I recall, there are no requirements that the
>> location stated in the CRLDP need to be used to obtain the CRL.
>> 
>> The URL stated in CDP may further be relative (and refer the
>> relying party to the resource on the local network).
>> 
>> /Stefan.
>> 
>> 
>> On 09-07-15 4:02 PM, "Jean-Marc Desperrier" <[email-masked]> wrote:
>> 
>>> 
>>> The text of RFC5280 says :
>>> 4.2.1.14 CRL Distribution Points
>>>      [...] this profile
>>>      recommends support for this extension by CAs and applications.
>>> 
>>> Whilst I 100% approve the recommendation for CAs (No CA
>> should issue 
>>> certificates without CRLDP when they do provide CRL), what
>> does it in 
>>> practice mean for applications ?
>>> 
>>> They are cases where dynamically  downloading the CRL by
>> interpreting 
>>> the CRL DP extension is inappropriate for some
>> applications, and where
>>> the needs and context of the application make it much more
>> adequate to 
>>> instead to configure in advance the location where the CRL of the
>>> supported CAs can be found.
>>> 
>>> Some examples  :
>>> - Closed networks : Network access to the open internet and
>> the CRL DP 
>>> might be simply unavailable, and the application should get
>> CRLs from 
>>> copies made at alternative locations on the local network.
>>> - Controled network : Even if no alternative local location is
>>> provided, network rules may forbid network  access that has
>> not been 
>>> vetted beforehand, so make it inappropriate if the
>> application tries
>>> to download data from a location based on the information
>> contained in 
>>> any the certificate it just received
>>> - Performance : When the application has to validate a hich
>> volume of 
>>> certificates, dynamic loading of the CRL is simply
>> inappropriate. This
>>> can be worked around by using caching mechanisms, but it
>> will be more 
>>> adequate to use configuration particularly if the
>> application already
>>> configures rules about how often to download new CRLs (CRLS quite
>>> often are renewed more frequently than their nextUpdate
>> field signals, 
>>> some CA renew their CRL every day, but have a nextUpdate
>> filed valid for one week).
>>> 
>>> So whilst it's very useful to have the CA include the information
>>> inside the certificate, I think the standard should not try to
>>> constrain the methods by which the application will get it's up to
>>> date revocation info, or make it clearer that the use of
>> alternates is 
>>> appropriate when they will give the same result.
>>> 
>>> Can I have confirmation from the group that the text in RFC5280 is
>>> *not* intended to discourage applications under such circumstances
>>> from using configuration settings instead of dynamically
>> reading the 
>>> CRL DP extension content  ?
>>> 
>>> 
>> 
>> 
>> 

Date: Mon, 20 Jul 2009 06:40:03 +1000
From: Stephen Wilson <[email-masked]>
To: ietf-pkix <[email-masked]>
Subject: Relieving CAs of 'ultimate responsibility' [was: Way forward - updating RFC 3161] 
Sender: [email-masked]

Stefan Santesson wrote:
>
> Note that we have a very similar [role separation] situation with PKI. 
> The CA issues certificates, but in practice the CA will delegate the 
> signing to a “unit” and may delegate authorization of attributes to 
> “Registration Authority”. Still, the CA is ultimately the responsible 
> party and not any “unit” or other subordinate entity or process.
Ultimately, the CA is responsible for what exactly? In orthodox PKI, the 
CA is responsible for everything, and hence we got ourselves into a 
quagmire of unwieldy thick CPs, legal agreements and untold risks. This 
despite the fact that most liabilities arise in mis-registration.

But there is a way to relieve CAs of many risks, and at the same time 
simplify the legal principles, the user agreements and the PKI business 
model: treat the CA like a Security Printer. Like a cheque printer, a CA 
should only be responsible for the quality of the certificates (cheques) 
but not their content.

See http://www.lockstep.com.au/library/pki/the_security_printer_model_fo.

Cheers,

Stephen Wilson
Managing Director
Lockstep Group

Phone +61 (0)414 488 851

www.lockstep.com.au <http://www.lockstep.com.au>
-------------------
Lockstep Consulting provides independent specialist advice and analysis
on digital identity and privacy. Lockstep Technologies develops unique
new smart ID solutions that enhance privacy and prevent identity theft.
-----------------------------------------------------------------------
* Finextra Innovation Showcase 2009
* ABC TV 'The New Inventors' Nov 2008
* Global Security Challenge Asia Top Five 2008
* Australian Technology Showcase 2008
* AusIndustry COMET Grant 2007

Date: Sun, 19 Jul 2009 19:26:18 +0200
From: Peter Sylvester <[email-masked]>
To: Russ Housley <[email-masked]>
Cc: ietf-pkix <[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Sender: [email-masked]

Russ Housley wrote:
>
>
>>     No doubt that everybody agrees that RFC 3161 should be updated to
>>     allow the use of RFC 5035 [ESSV2].
>
> I agree that this change is desirable to support the smooth transition 
> to bigger hash values than SHA-1.
>
> Russ
>
To be sure: You didn't say whether you think it would be necessary
or useful to have bigger hash values thta sha-1, i.e.
to implement  "the smooth transition" in this case.

Peter

Date: Sun, 19 Jul 2009 19:21:45 +0200
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: [email-masked], ietf-pkix <[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Sender: [email-masked]

This is a multi-part message in MIME format.
--------------060806020509080603090304
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

>
>     No doubt that everybody agrees that RFC 3161 should be updated to
>     allow the use of RFC 5035 [ESSV2].
>
It doesn't harm to optionally allow essv2.
That doesn't mean that one should remove the existing signed attribute.
>
>     The question is whether other changes should also be made.
>
>     The major differences from RFC 3161 [RFC3161] are summarized on
>     page 3 of the draft and are listed below:
>
>          1 - the document has been aligned with RFC 3628 to make the
>              difference between a time-stamping unit (TSU) and a TSA.
>
rfc 3628 is an informational rfc. It may be useful to consider a TSU, but
this is not required. although 3161 may be confusing for some, but
not more than those that use the term "CA" for many different things,
in all cases, the 3161 text doesn't seem to require any change imo.
It is sufficiently clear imo whether one talks about a technical entity,
a signing device, or some organisational entity.
>
>
>          2 - the document makes the difference between a time-stamping
>              service and a time-stamping unit and allows a time-stamping
>              service to support more than one time-stamping unit.
>
as an organisation or a operator, a "CA" may operate several HSMs etc etc,
there is no difference. It is even an unnecessary overspecification.
>
>
>          3 - the format of the subject field of a TSU certificate is now
>              defined.
>
And confusion with the "tsa" field in tstinfo added.
>
>
>     and also some minor updates :
>
>          4 - informative references to ISO 18014-1 [ISO18014-1],
>              ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3]
>     have been
>              added.
>
>          5 - a new normative ASN1 module to refer to the ASN.1 modules
>              from the latest RFCs.
>
Whow, that indeed very important.
>
>
>     At the moment, RFC 3161 makes confusion between three different
>     concepts:
>     a TSA, a TSS and a TSU, respectively a Time-Stamping Authority,
>     a Time-Stamping Service and a Time-Stamping Unit.
>
No, it doesn't.
>
>
>     IMO, the document should be cleaned to call a spade a spade.
>
others don't seem to share this.
>
>
>     Historically, the notions applicable to TSAs have been copied and
>     pasted
>     from the documents related to CAs. Since a CA had one private key,
>     a TSA
>     had one private key as well, but this was short looking.
>
a ca had only one key? since when? what you describe for a tsa, can as 
well apply
to a CA, using several HSMs in parallel which are clones and maybe operated
in different places.
>
>
>     The CA advertises one public key, or more exactly one trust
>     anchor, usually
>     by issuing a self-signed certificate. This private key, when in use,
>     is supported by one HSH (Hardware Security Module). This private
>     key needs
>     to be saved in order to be restored in case of a problem. The time
>     for restoration
>     is usually not critical (this may take a few minutes or even a few
>     hours).
>     The life time of a CA certificate (or CA public key) is usually
>     between one and
>     15 years and should not be changed earlier, unless strictly needed.
>
I am not sure what you mean by CA here.
>
>
>     In order to provide time-stamp tokens (TSTs) with high
>     availability, more than
>     one TSU is usually needed. These units altogether provide a TSS
>     (Time-Stamping Service)
>     that is managed by an Authority called a TSA (Time-Stamping
>     Authority).
>
That' a possible way to describe or organise these things, but not the 
only one.
Ambiguous or slightly misused wording is well known in this field,
the major example being 'certificate'.

>
>     The key used to sign TSTs is not the key from a TSA, but the key
>     from a TSU.
>
IMO  'the key from a TSA/U' is not a sufficiently well defined
definition to make a distinction.

>
>     In order to a high level of security, the key used to sign to TSTs
>     should NOT be saved
>     and restored. It should be generated by the TSU itself and should
>     NOT be exported
>     outside the TSU. If the key of the TSU is erased purposely or by
>     accident, a new key pair
>     and certificate should be generated. 
>
Whether done or not, none of this has an impact to the protocol.
(To be clear, I do not comment on what you wrote).
 
>
>     Since TSU certificates are provided by a CA,
>     TST verification systems do not need to change any trust anchor.
>     Some TSUs may even
>     use short-lived TSU certificates, e.g. a TSU certificate valid for
>     one week or even one day.
>
and, where is the beef?
>
>
>     However, it is necessary to be able to know the name of the TSA
>     when looking at the
>     subject DN from the TSU certificate.
>
for what purpose, and, in fact, that's the point which is bad in the 
draft, what is the
name of (your definition of) the tsa when you look at the subject dn?
>
>
>     Along these lines, several changes should be made to RFC 3161. To
>     mention a few of them:
>
>     RFC 3161:
>       If the TSA does not recognize the hash
>       algorithm or knows that the hash algorithm is weak (a decision left
>       to the discretion of each individual TSA), then the TSA SHOULD
>     refuse
>       to provide the time-stamp token by returning a pkiStatusInfo of
>       'bad_alg'.
>
>     Proposed change :
>       If the TSS does not recognize the hash
>       algorithm or knows that the hash algorithm is weak (a decision left
>         to the discretion of each individual TSA), then the TSS SHOULD
>     refuse
>       to provide the time-stamp token by returning a pkiStatusInfo of
>       'bad_alg'.
>
any of your three meanings of tsu, tss, tsa applies to the text. The tsa 
takes the
resonsibility, the tss as a global service deliveres what one of the 
tsus create.
>
>
>     RFC3161:
>       The certificate identifier (ESSCertID) of the
>        TSA certificate MUST be included as a signerInfo attribute
>     inside a
>       SigningCertificate attribute.
>
>     Proposed change:
>       The certificate identifier (either ESSCertID  or ESSCertIDv2) of
>     the TSU certificate
>       MUST be included as a signerInfo attribute inside a
>     SigningCertificate attribute.
>
Rejected. The ESSCertId MUST be provided. An ESSCertIDV2 MAY be 
optionally added.
>
>
>     RFC 3161:
>       The serialNumber field is an integer assigned by the TSA to each
>     TimeStampToken.
>
>     Proposed change:
>       The serialNumber field is an integer assigned by the TSU to each
>      TimeStampToken.
>
This seems an overspecification. nothing is wrong, if a global TSA 
concentrator
allocates unique serialnumbers for its backend signing machines.
>
>
>     RFC 3161:
>       genTime is the time at which the time-stamp token has been
>     created by
>      
>       the TSA.
>
>     Proposed change:
>       genTime is the time at which the time-stamp token has been
>     created by
>        the TSU.
>
Idem. In fact, the text could say: Indicates the time that a TSA is 
willing to
assert.
>
>
>     RF3161:
>       The purpose of the tsa field is to give a hint in identifying the
>        name of the TSA.
>
>     Proposed change:
>       The purpose of the tsu field is to give a hint in identifying the
>       name of the TSU.
>
it is unacceptable to change the "name" of a field. although it may be
considered as irrelevant, it makes a difference when you use XER to
display things.

I also recommend Lewis Carroll:  "A hint in identifying a name".

Is this te name, or how you call the name, you a hint for that?

http://www.edelweb.fr/EdelStuff/Prospectus/ibmmail.txt

>
>     Note that the difference between a TSU and a TSA that is already
>     present
>     in RFC 3628 (Informational) is also present in ISO 18014 and in
>     ETSI TS 102 023.
>     All these documents have been issued after RFC 3161.
>
This is not an argument to copy them. There may also be
a reason for RFC 3628 being informational and not standards track.
the "dad, mon has already agreed" argument is more than weak here
>
>
>     Even, if the bits on the wire are the same, the meaning of these bits
>     would not necessarily be the same. For example, the ESSCertID
>     refers to
>     a  certificate from a TSU, not from a TSA.
>
And what does this mean in practice? What is a relying party supposed to do?
where would it get the name of a tsa? Is there a need to change something
at the relying party?

>
>     Since the changes to be done are scattered around the document, a
>     new draft
>     would seem more appropriate, hence why a new draft has been proposed.
>
This we have understood, but none of the changes seem useful or 
necessary, some
even are restrictive  and introduce unnecessary  modification.
>
>
>     From another angle, should we have an update to RFC 3161 or a new
>     draft?
>     An update would have to advantage to keep the magic number 3161
>     that everybody
>     identifies with TSP.
>
I think that was already discussed. no replacement.
>
>
>     In any case, I believe that both the ESSCertIDv2 and the
>     terminology aspects
>     should be addressed to align RFC 3161 with the documents issued
>     after it.
>
I'd recommend to do this in two different texts. ESSCertID2 as the one 
sentence
above.

"ESSCertID2 for RFC 3161".

Abstract

RFC 3161 use esssSigningCert to reference a signing certificat. This
document proposes a potentially cryptographically stronger reference by
using essv2. backward compatibility is ensured.

After the sentence of RFC3161:
  "The certificate identifier (ESSCertID) of the
   TSA certificate MUST be included as a signerInfo attribute inside a
  SigningCertificate attribute."

insert:

"An ESSCertIDV2 MAY be added in order to allow a smooth transition
stronger hash functions."

To be discussed what has to be done by an RP in case of no essv2
(basically no change), or one with an unknown algorithm:
MUST NOT reject a timestamp solely on the base that there is either
no essv2 or the essv2contains an unsupported algorithm.
I hate that phrase. :-)

and :

 "Clarifications on the meaning of the TSA tla"

abstract: RFC 3161 used the tla TSA for different purposes. This text
clarifiesthe different usages and redefines the tla, and introduces
two new tlas in alignment with 3628 etc. No technical change occurs
at the protocol level.

Peter

--------------060806020509080603090304
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
  <title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
    </span> <span>No doubt that everybody agrees that RFC 3161 should
be updated to allow the use of RFC 5035 [ESSV2]. <br>
    </span></blockquote>
</blockquote>
It doesn't harm to optionally allow essv2. <br>
That doesn't mean that one should remove the existing signed attribute.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span>The question is whether other changes should also
be made.<br>
    <br>
The major differences from RFC 3161 [RFC3161] are summarized on page 3
of the draft and are listed below:<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 - the document has been aligned with RFC 3628 to make the <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;difference between a time-stamping unit (TSU) and a TSA.<br>
    </span></blockquote>
</blockquote>
rfc 3628 is an informational rfc. It may be useful to consider a TSU,
but<br>
this is not required. although 3161 may be confusing for some, but<br>
not more than those that use the term "CA" for many different things,<br>
in all cases, the 3161 text doesn't seem to require any change imo.<br>
It is sufficiently clear imo whether one talks about a technical entity,<br>
a signing device, or some organisational entity.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2 - the document makes the difference between a time-stamping <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service and a time-stamping unit and allows a time-stamping <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service to support more than one time-stamping unit.<br>
    </span></blockquote>
</blockquote>
as an organisation or a operator, a "CA" may operate several HSMs etc
etc,<br>
there is no difference. It is even an unnecessary overspecification.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3 - the format of the subject field of a TSU certificate is now <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defined.<br>
    </span></blockquote>
</blockquote>
And confusion with the "tsa" field in tstinfo added.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
and also some minor updates :<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4 - informative references to ISO 18014-1 [ISO18014-1], <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have
been <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;added.<br>
    <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5 - a new normative ASN1 module to refer to the ASN.1 modules <br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from the latest RFCs. <br>
    </span></blockquote>
</blockquote>
Whow, that indeed very important. <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>At the moment, RFC 3161 makes confusion between
three different concepts: <br>
a TSA, a TSS and a TSU, respectively a Time-Stamping Authority, <br>
a Time-Stamping Service and a Time-Stamping Unit. <br>
    </span></blockquote>
</blockquote>
No, it doesn't. <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span></span> <span> <br>
    </span> <span> IMO, the document should be cleaned to call a spade
a spade.<br>
    </span></blockquote>
</blockquote>
others don't seem to share this.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
Historically, the notions applicable to TSAs have been copied and
pasted <br>
from the documents related to CAs. Since a CA had one private key, a
TSA <br>
had one private key as well, but this was short looking.<br>
    </span></blockquote>
</blockquote>
a ca had only one key? since when? what you describe for a tsa, can as
well apply<br>
to a CA, using several HSMs in parallel which are clones and maybe
operated<br>
in different places. <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
The CA advertises one public key, or more exactly one trust anchor,
usually <br>
by issuing a self-signed certificate. This private key, when in use, <br>
is supported by one HSH (Hardware Security Module). This private key
needs <br>
to be saved in order to be restored in case of a problem. The time for
restoration <br>
is usually not critical (this may take a few minutes or even a few
hours). <br>
The life time of a CA certificate (or CA public key) is usually between
one and <br>
15 years and should not be changed earlier, unless strictly needed.<br>
    </span></blockquote>
</blockquote>
I am not sure what you mean by CA here. <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
In order to provide time-stamp tokens (TSTs) with high availability,
more than <br>
one TSU is usually needed. These units altogether provide a TSS
(Time-Stamping Service) <br>
that is managed by an Authority called a TSA (Time-Stamping Authority).<br>
    </span></blockquote>
</blockquote>
That' a possible way to describe or organise these things, but not the
only one.<br>
Ambiguous or slightly misused wording is well known in this field,<br>
the major example being 'certificate'.<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
The key used to sign TSTs is not the key from a TSA, but the key from a
TSU.<br>
    </span></blockquote>
</blockquote>
IMO&nbsp; 'the key from a TSA/U' is not a sufficiently well defined <br>
definition to make a distinction.<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
In order to a high level of security, the key used to sign to TSTs
should NOT be saved <br>
and restored. It should be generated by the TSU itself and should NOT
be exported <br>
outside the TSU. If the key of the TSU is erased purposely or by
accident, a new key pair <br>
and certificate should be generated. </span></blockquote>
</blockquote>
Whether done or not, none of this has an impact to the protocol. <br>
(To be clear, I do not comment on what you wrote).<br>
&nbsp;<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span>Since TSU certificates are provided by a CA, <br>
TST verification systems do not need to change any trust anchor. Some
TSUs may even <br>
use short-lived TSU certificates, e.g. a TSU certificate valid for one
week or even one day.</span></blockquote>
</blockquote>
and, where is the beef?<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span> <br>
However, it is necessary to be able to know the name of the TSA when
looking at the <br>
subject DN from the TSU certificate.<br>
    </span></blockquote>
</blockquote>
for what purpose, and, in fact, that's the point which is bad in the
draft, what is the<br>
name of (your definition of) the tsa when you look at the subject dn? <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
Along these lines, several changes should be made to RFC 3161. To
mention a few of them:<br>
    <br>
RFC 3161:<br>
    </span> <span> &nbsp;&nbsp;If the TSA does not recognize the hash</span> <span>
    <br>
    </span> <span> &nbsp;&nbsp;algorithm or knows that the hash algorithm is
weak (a decision left</span> <span> <br>
    </span> <span> &nbsp;&nbsp;to the discretion of each individual TSA), then
the TSA SHOULD refuse</span> <span> <br>
    </span> <span> &nbsp;&nbsp;to provide the time-stamp token by returning a
pkiStatusInfo of</span> <span> <br>
    </span> <span> &nbsp;&nbsp;'bad_alg'.<br>
    </span> <span><br>
    </span> <span>Proposed change :<br>
    </span> <span> &nbsp;&nbsp;If the TSS does not recognize the hash</span> <span>
    <br>
    </span> <span> &nbsp;&nbsp;algorithm or knows that the hash algorithm is
weak (a decision left</span> <span> <br>
&nbsp;</span> <span> &nbsp;&nbsp;to the discretion of each individual TSA), then the
TSS SHOULD refuse</span> <span> <br>
    </span> <span> </span> <span> &nbsp;&nbsp;to provide the time-stamp token
by returning a pkiStatusInfo of</span> <span> <br>
    </span> <span> </span> <span> &nbsp;&nbsp;'bad_alg'.<br>
    </span></blockquote>
</blockquote>
any of your three meanings of tsu, tss, tsa applies to the text. The
tsa takes the<br>
resonsibility, the tss as a global service deliveres what one of the
tsus create.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>RFC3161:<br>
    </span> <span> &nbsp;&nbsp;The certificate identifier (ESSCertID) of the</span>
    <span> <br>
&nbsp;</span> <span> &nbsp;TSA certificate MUST be included as a signerInfo
attribute inside a</span> <span> <br>
    </span> <span> &nbsp;</span> <span>SigningCertificate attribute.<br>
    <br>
Proposed change:<br>
    </span> <span> &nbsp;&nbsp;The certificate identifier (either ESSCertID &nbsp;or
ESSCertIDv2) of the TSU certificate <br>
&nbsp;&nbsp;MUST be included as a </span> <span>signerInfo attribute inside a
SigningCertificate attribute.<br>
    </span></blockquote>
</blockquote>
Rejected. The ESSCertId MUST be provided. An ESSCertIDV2 MAY be
optionally added.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
RFC 3161:<br>
    </span> <span> &nbsp;&nbsp;The serialNumber field is an integer assigned by
the TSA to each</span> <span> <br>
    </span> <span> </span> <span> TimeStampToken.<br>
    <br>
Proposed change: <br>
    </span> <span> &nbsp;&nbsp;The serialNumber field is an integer assigned by
the TSU to each</span> <span> <br>
    </span> <span> </span> <span> &nbsp;TimeStampToken.<br>
    </span></blockquote>
</blockquote>
This seems an overspecification. nothing is wrong, if a global TSA
concentrator<br>
allocates unique serialnumbers for its backend signing machines.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>RFC 3161:<br>
    </span> <span> &nbsp;&nbsp;genTime is the time at which the time-stamp token
has been created by</span> <span> <br>
&nbsp;<br>
    </span> <span> &nbsp;&nbsp;the TSA.<br>
    </span> <span><br>
    </span> <span>Proposed change:<br>
    </span> <span> &nbsp;&nbsp;genTime is the time at which the time-stamp token
has been created by</span> <span> <br>
&nbsp;</span> <span> &nbsp;the TSU.<br>
    </span></blockquote>
</blockquote>
Idem. In fact, the text could say: Indicates the time that a TSA is
willing to<br>
assert. <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>RF3161:<br>
    </span> <span> &nbsp;&nbsp;The purpose of the tsa field is to give a hint in
identifying the</span> <span> <br>
&nbsp;</span> <span> &nbsp;name of the TSA.<br>
    </span> <span><br>
    </span> <span>Proposed change:<br>
    </span> <span> &nbsp;&nbsp;The purpose of the tsu field is to give a hint in
identifying the</span> <span> <br>
    </span> <span> &nbsp;&nbsp;name of the TSU.<br>
    </span></blockquote>
</blockquote>
it is unacceptable to change the "name" of a field. although it may be<br>
considered as irrelevant, it makes a difference when you use XER to<br>
display things. <br>
<br>
I also recommend Lewis Carroll:&nbsp; "A hint in identifying a name".<br>
<br>
Is this te name, or how you call the name, you a hint for that?<br>
<br>
<a class="moz-txt-link-freetext" href="http://www.edelweb.fr/EdelStuff/Prospectus/ibmmail.txt">http://www.edelweb.fr/EdelStuff/Prospectus/ibmmail.txt</a><br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span></span> <span><br>
    </span> <span>Note that the difference between a TSU and a TSA
that is already present <br>
in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS
102 023.<br>
All these documents have been issued after RFC 3161.<br>
    </span></blockquote>
</blockquote>
This is not an argument to copy them. There may also be <br>
a reason for RFC 3628 being informational and not standards track.<br>
the "dad, mon has already agreed" argument is more than weak here<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
Even, if the bits on the wire are the same, the meaning of these bits <br>
would not necessarily be the same. For example, the ESSCertID refers to
    <br>
a &nbsp;certificate from a TSU, not from a TSA.<br>
    </span></blockquote>
</blockquote>
And what does this mean in practice? What is a relying party supposed
to do?<br>
where would it get the name of a tsa? Is there a need to change
something<br>
at the relying party?<br>
<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
Since the changes to be done are scattered around the document, a new
draft <br>
would seem more appropriate, hence why a new draft has been proposed.<br>
    </span></blockquote>
</blockquote>
This we have understood, but none of the changes seem useful or
necessary, some <br>
even are restrictive&nbsp; and introduce unnecessary&nbsp; modification. <br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
>From another angle, should we have an update to RFC 3161 or a new
draft? <br>
An update would have to advantage to keep the magic number 3161 that
everybody <br>
identifies with TSP.<br>
    </span></blockquote>
</blockquote>
I think that was already discussed. no replacement.<br>
<blockquote cite="mid:[email-masked]" type="cite">
  <blockquote><span><br>
In any case, I believe that both the ESSCertIDv2 and the terminology
aspects <br>
should be addressed to align RFC 3161 with the documents issued after
it. <br>
    </span></blockquote>
</blockquote>
I'd recommend to do this in two different texts. ESSCertID2 as the one
sentence<br>
above.<br>
<br>
<br>
"ESSCertID2 for RFC 3161".<br>
<br>
Abstract <br>
<br>
RFC 3161 use esssSigningCert to reference a signing certificat. This<br>
document proposes a potentially cryptographically stronger reference by<br>
using essv2. backward compatibility is ensured.<br>
<br>
<span>After the sentence of RFC3161:<br>
</span> <span> &nbsp; "The certificate identifier (ESSCertID) of the</span>
<span> <br>
&nbsp;</span> <span> &nbsp;TSA certificate MUST be included as a signerInfo
attribute inside a</span> <span> <br>
</span> <span> &nbsp;</span> <span>SigningCertificate attribute."<br>
<br>
insert:<br>
<br>
</span> "An ESSCertIDV2 MAY be added in order to allow a smooth
transition<br>
stronger hash functions."<br>
<br>
To be discussed what has to be done by an RP in case of no essv2<br>
(basically no change), or one with an unknown algorithm: <br>
MUST NOT reject a timestamp solely on the base that there is either<br>
no essv2 or the essv2contains an unsupported algorithm.<br>
I hate that phrase. :-)<br>
<span></span><br>
and :<br>
<br>
&nbsp;"Clarifications on the meaning of the TSA tla" <br>
<br>
abstract: RFC 3161 used the tla TSA for different purposes. This text<br>
clarifiesthe different usages and redefines the tla, and introduces<br>
two new tlas in alignment with 3628 etc. No technical change occurs<br>
at the protocol level.<br>
<br>
Peter<br>
<br>
<br>
<br>
<br>
<br>
<br>
</body>
</html>

--------------060806020509080603090304--

Date: Sun, 19 Jul 2009 11:38:03 -0400
To: ietf-pkix <[email-masked]>
From: Russ Housley <[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Sender: [email-masked]

>     No doubt that everybody agrees that RFC 3161 should be updated to
>     allow the use of RFC 5035 [ESSV2].

I agree that this change is desirable to support the smooth 
transition to bigger hash values than SHA-1.

Russ

Content-class: urn:content-classes:message
Subject: RE: RFC5280 : Applications and CRL DP extension support
Date: Sun, 19 Jul 2009 11:24:10 -0400
From: "Santosh Chokhani" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Jean-Marc Desperrier" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Stefan,

The imprecision in the statement below can lead to security problem.  If
IDP is present in a CRL with DP in the IDP, even if there is no CRL DP
in the certificate, that CRL with DP in IDP can not be used by relying
parties since whether the CRL covers the scope of the certificate or
not, is unknown.

> From: [email-masked]=20
> Sent: Sunday, July 19, 2009 10:24 AM
> To: Jean-Marc Desperrier; [email-masked]
> Subject: Re: RFC5280 : Applications and CRL DP extension support
>=20
>=20
> Jean,
>=20
> An aspect of this often forgotten is that a major practical=20
> function of the CRLDP is to act as an identifier used to=20
> match the certificate and the CRL.
>=20
> When a CRLDP is present in a certificate and an Issuing=20
> Distribution point extension is present in the CRL, them the=20
> distribution points of these extensions MUST match as defined=20
> in section 5.2.5 of RFC 5280.
>=20
> As far as I recall, there are no requirements that the=20
> location stated in the CRLDP need to be used to obtain the CRL.
>=20
> The URL stated in CDP may further be relative (and refer the=20
> relying party to the resource on the local network).
>=20
> /Stefan.
>=20
>=20
> On 09-07-15 4:02 PM, "Jean-Marc Desperrier" <[email-masked]> wrote:
>=20
> >=20
> > The text of RFC5280 says :
> > 4.2.1.14 CRL Distribution Points
> >      [...] this profile
> >      recommends support for this extension by CAs and applications.
> >=20
> > Whilst I 100% approve the recommendation for CAs (No CA=20
> should issue=20
> > certificates without CRLDP when they do provide CRL), what=20
> does it in=20
> > practice mean for applications ?
> >=20
> > They are cases where dynamically  downloading the CRL by=20
> interpreting=20
> > the CRL DP extension is inappropriate for some=20
> applications, and where=20
> > the needs and context of the application make it much more=20
> adequate to=20
> > instead to configure in advance the location where the CRL of the=20
> > supported CAs can be found.
> >=20
> > Some examples  :
> > - Closed networks : Network access to the open internet and=20
> the CRL DP=20
> > might be simply unavailable, and the application should get=20
> CRLs from=20
> > copies made at alternative locations on the local network.
> > - Controled network : Even if no alternative local location is=20
> > provided, network rules may forbid network  access that has=20
> not been=20
> > vetted beforehand, so make it inappropriate if the=20
> application tries=20
> > to download data from a location based on the information=20
> contained in=20
> > any the certificate it just received
> > - Performance : When the application has to validate a hich=20
> volume of=20
> > certificates, dynamic loading of the CRL is simply=20
> inappropriate. This=20
> > can be worked around by using caching mechanisms, but it=20
> will be more=20
> > adequate to use configuration particularly if the=20
> application already=20
> > configures rules about how often to download new CRLs (CRLS quite=20
> > often are renewed more frequently than their nextUpdate=20
> field signals,=20
> > some CA renew their CRL every day, but have a nextUpdate=20
> filed valid for one week).
> >=20
> > So whilst it's very useful to have the CA include the information=20
> > inside the certificate, I think the standard should not try to=20
> > constrain the methods by which the application will get it's up to=20
> > date revocation info, or make it clearer that the use of=20
> alternates is=20
> > appropriate when they will give the same result.
> >=20
> > Can I have confirmation from the group that the text in RFC5280 is=20
> > *not* intended to discourage applications under such circumstances=20
> > from using configuration settings instead of dynamically=20
> reading the=20
> > CRL DP extension content  ?
> >=20
> >=20
>=20
>=20
>=20

Date: Sun, 19 Jul 2009 16:23:40 +0200
Subject: Re: RFC5280 : Applications and CRL DP extension support
From: Stefan Santesson <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Jean,

An aspect of this often forgotten is that a major practical function of the
CRLDP is to act as an identifier used to match the certificate and the CRL.

When a CRLDP is present in a certificate and an Issuing Distribution point
extension is present in the CRL, them the distribution points of these
extensions MUST match as defined in section 5.2.5 of RFC 5280.

As far as I recall, there are no requirements that the location stated in
the CRLDP need to be used to obtain the CRL.

The URL stated in CDP may further be relative (and refer the relying party
to the resource on the local network).

/Stefan.

On 09-07-15 4:02 PM, "Jean-Marc Desperrier" <[email-masked]> wrote:

> 
> The text of RFC5280 says :
> 4.2.1.14 CRL Distribution Points
>      [...] this profile
>      recommends support for this extension by CAs and applications.
> 
> Whilst I 100% approve the recommendation for CAs (No CA should issue
> certificates without CRLDP when they do provide CRL), what does it in
> practice mean for applications ?
> 
> They are cases where dynamically  downloading the CRL by interpreting
> the CRL DP extension is inappropriate for some applications, and where
> the needs and context of the application make it much more adequate to
> instead to configure in advance the location where the CRL of the
> supported CAs can be found.
> 
> Some examples  :
> - Closed networks : Network access to the open internet and the CRL DP
> might be simply unavailable, and the application should get CRLs from
> copies made at alternative locations on the local network.
> - Controled network : Even if no alternative local location is provided,
> network rules may forbid network  access that has not been vetted
> beforehand, so make it inappropriate if the application tries to
> download data from a location based on the information contained in any
> the certificate it just received
> - Performance : When the application has to validate a hich volume of
> certificates, dynamic loading of the CRL is simply inappropriate. This
> can be worked around by using caching mechanisms, but it will be more
> adequate to use configuration particularly if the application already
> configures rules about how often to download new CRLs (CRLS quite often
> are renewed more frequently than their nextUpdate field signals, some CA
> renew their CRL every day, but have a nextUpdate filed valid for one week).
> 
> So whilst it's very useful to have the CA include the information inside
> the certificate, I think the standard should not try to constrain the
> methods by which the application will get it's up to date revocation
> info, or make it clearer that the use of alternates is appropriate when
> they will give the same result.
> 
> Can I have confirmation from the group that the text in RFC5280 is *not*
> intended to discourage applications under such circumstances from using
> configuration settings instead of dynamically reading the CRL DP
> extension content  ?
> 
> 

Date: Sun, 19 Jul 2009 16:14:41 +0200
Subject: Re: Way forward - updating RFC 3161
From: Stefan Santesson <[email-masked]>
To: Peter Sylvester <[email-masked]>
CC: <[email-masked]>, ietf-pkix <[email-masked]>
Sender: [email-masked]

Peter,

I have argued in support of your position and lost.
This work group has already decided to optionally allow a stronger hash than
SHA-1 to bind the signing certificate.

I would agree that no one has identified any realistic attack that would
require this response, but there is a point to do this anyway just to be
technically in line with other standards bodies and current deployment.

/Stefan

On 09-07-19 3:50 PM, "Peter Sylvester" <[email-masked]> wrote:

> 
> 
>> 
>> 
>>     No doubt that everybody agrees that RFC 3161 should be updated to
>>     allow the use of RFC 5035 [ESSV2].
>>     The question is whether other changes should also be made.
>> 
> I do not agree with that at all. I'd not even think thae the
> essSigningCert serves
> anything.
> 
> A requirement of the EU Electronic Signature Directive is that a signature
> must identify the signer. The tsa field in the tstinfo is imo sufficient and
> has the advantage being explicit.
> 
> 
> 

Date: Sun, 19 Jul 2009 15:50:24 +0200
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: [email-masked], ietf-pkix <[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Sender: [email-masked]

>
>
>     No doubt that everybody agrees that RFC 3161 should be updated to
>     allow the use of RFC 5035 [ESSV2].
>     The question is whether other changes should also be made.
>
I do not agree with that at all. I'd not even think thae the 
essSigningCert serves
anything.

A requirement of the EU Electronic Signature Directive is that a signature
must identify the signer. The tsa field in the tstinfo is imo sufficient and
has the advantage being explicit.

Date: Sun, 19 Jul 2009 14:44:40 +0200
Subject: Re: Request for PKIX agenda items - IETF 75
From: Stefan Santesson <[email-masked]>
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3330859481_13131838
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

All,

The response to this has been very thin. Hopefully because of vacations and
stuff. But I really need to know if you need a slot at the meeting or not.
I will post a preliminary agenda in a few days, but right now it looks quite
thin.

So unless you want really long presentations by me, please send in your
requests ASAP :)

/Stefan

On 09-06-29 9:36 PM, "Stefan Santesson" <[email-masked]> wrote:

> PKIX is currently scheduled to meet on Wednesday July 29, 1300-1500
> 
> Please send me any request for agenda items for the IETF in Stockholm.
> 
> As usual I need at least one author of each active draft to send me an e-mail
> stating if you need a slot or not.
> 
> I myself will request (and grant unless I hear loud objections) a time slot to
> talk about solutions for expanded attribute semantics expression. This is an
> issue that sorts under liaison with ETSI ESI activities as well as European ID
> management projects.
> 
> /Stefan

--B_3330859481_13131838
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Request for PKIX agenda items - IETF 75</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>All,<BR>
<BR>
The response to this has been very thin. Hopefully because of vacations and=
 stuff. But I really need to know if you need a slot at the meeting or not.<=
BR>
I will post a preliminary agenda in a few days, but right now it looks quit=
e thin.<BR>
<BR>
So unless you want really long presentations by me, please send in your req=
uests ASAP :)<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-06-29 9:36 PM, &quot;Stefan Santesson&quot; &lt;<a href=3D"stefan@aaa-s=
ec.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN STYLE=3D'font-size:11pt'>PKIX is currently scheduled to meet on Wednesday=
 July 29, 1300-1500<BR>
<BR>
Please send me any request for agenda items for the IETF in Stockholm.<BR>
<BR>
As usual I need at least one author of each active draft to send me an e-ma=
il stating if you need a slot or not.<BR>
<BR>
I myself will request (and grant unless I hear loud objections) a time slot=
 to talk about solutions for expanded attribute semantics expression. This i=
s an issue that sorts under liaison with ETSI ESI activities as well as Euro=
pean ID management projects.<BR>
<BR>
/Stefan<BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3330859481_13131838--

Date: Sun, 19 Jul 2009 14:39:23 +0200
Subject: Re: Way forward - updating RFC 3161
From: Stefan Santesson <[email-masked]>
To: <[email-masked]>, ietf-pkix <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3330859164_13106136
Content-type: text/plain;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

Denis,

I have seen your response and waited to see if someone is stepping up to
support you, but it seems that you are quite alone in your urge to update
the terminology and role separation of the time stamping protocol.

My primary issue is not whether the role separation is accurate and well
motivated. The central issue for me is why it need to be included in the
protocol specification.
Note that we have a very similar situation with PKI. The CA issues
certificates, but in practice the CA will delegate the signing to a =B3unit=B2
and may delegate authorization of attributes to  =B3Registration Authority=B2.
Still, the CA is ultimately the responsible party and not any =B3unit=B2 or
other subordinate entity or process. The same is true for a TSA. The TSA is
the responsible entity and as such the entity that is represented by the
certificate of the service, even if that certificate indicates which unit
under the TSA control that actually signed the Time-stamp.

As long as this does not reflect any bits on the wire, it would just be
confusing to define the role separation structure behind the service as par=
t
of the protocol.

This is where I think you have failed to convince us.

Unless I hear new convincing arguments, I will treat the answers on this
list as a rough consensus decision to NOT make a full replacement of RFC
3161, but merely provide an update document with ESSCertIDv2 and possibly
similar minor updates, but to drop alignment with RFC 3628 terminology.

/Stefan

On 09-07-10 3:55 PM, "Denis Pinkas" <[email-masked]> wrote:

> =20
> No doubt that everybody agrees that RFC 3161 should be updated to allow t=
he
> use of RFC 5035 [ESSV2].
> The question is whether other changes should also be made.
>=20
> The major differences from RFC 3161 [RFC3161] are summarized on page 3 of=
 the
> draft and are listed below:
>=20
>      1 - the document has been aligned with RFC 3628 to make the
>          difference between a time-stamping unit (TSU) and a TSA.
>=20
>      2 - the document makes the difference between a time-stamping
>          service and a time-stamping unit and allows a time-stamping
>          service to support more than one time-stamping unit.
>=20
>      3 - the format of the subject field of a TSU certificate is now
>          defined.
>=20
> and also some minor updates :
>=20
>      4 - informative references to ISO 18014-1 [ISO18014-1],
>          ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been
>          added.
>=20
>      5 - a new normative ASN1 module to refer to the ASN.1 modules
>          from the latest RFCs.
>=20
> At the moment, RFC 3161 makes confusion between three different concepts:
> a TSA, a TSS and a TSU, respectively a Time-Stamping Authority,
> a Time-Stamping Service and a Time-Stamping Unit.
> =20
> IMO, the document should be cleaned to call a spade a spade.
>=20
> Historically, the notions applicable to TSAs have been copied and pasted
> from the documents related to CAs. Since a CA had one private key, a TSA
> had one private key as well, but this was short looking.
>=20
> The CA advertises one public key, or more exactly one trust anchor, usual=
ly
> by issuing a self-signed certificate. This private key, when in use,
> is supported by one HSH (Hardware Security Module). This private key need=
s
> to be saved in order to be restored in case of a problem. The time for
> restoration=20
> is usually not critical (this may take a few minutes or even a few hours)=
.
> The life time of a CA certificate (or CA public key) is usually between o=
ne
> and=20
> 15 years and should not be changed earlier, unless strictly needed.
>=20
> In order to provide time-stamp tokens (TSTs) with high availability, more=
 than
> one TSU is usually needed. These units altogether provide a TSS (Time-Sta=
mping
> Service)=20
> that is managed by an Authority called a TSA (Time-Stamping Authority).
>=20
> The key used to sign TSTs is not the key from a TSA, but the key from a T=
SU.
>=20
> In order to a high level of security, the key used to sign to TSTs should=
 NOT
> be saved=20
> and restored. It should be generated by the TSU itself and should NOT be
> exported=20
> outside the TSU. If the key of the TSU is erased purposely or by accident=
, a
> new key pair=20
> and certificate should be generated. Since TSU certificates are provided =
by a
> CA,=20
> TST verification systems do not need to change any trust anchor. Some TSU=
s may
> even=20
> use short-lived TSU certificates, e.g. a TSU certificate valid for one we=
ek or
> even one day.=20
> However, it is necessary to be able to know the name of the TSA when look=
ing
> at the=20
> subject DN from the TSU certificate.
>=20
> Along these lines, several changes should be made to RFC 3161. To mention=
 a
> few of them:
>=20
> RFC 3161:
>    If the TSA does not recognize the hash
>    algorithm or knows that the hash algorithm is weak (a decision left
>    to the discretion of each individual TSA), then the TSA SHOULD refuse
>    to provide the time-stamp token by returning a pkiStatusInfo of
>    'bad_alg'.
>=20
> Proposed change :
>    If the TSS does not recognize the hash
>    algorithm or knows that the hash algorithm is weak (a decision left
>     to the discretion of each individual TSA), then the TSS SHOULD refuse
>     to provide the time-stamp token by returning a pkiStatusInfo of
>     'bad_alg'.
>=20
> RFC3161:
>    The certificate identifier (ESSCertID) of the
>    TSA certificate MUST be included as a signerInfo attribute inside a
>   SigningCertificate attribute.
>=20
> Proposed change:
>    The certificate identifier (either ESSCertID  or ESSCertIDv2) of the T=
SU
> certificate=20
>   MUST be included as a signerInfo attribute inside a SigningCertificate
> attribute.
>=20
> RFC 3161:
>    The serialNumber field is an integer assigned by the TSA to each
>   TimeStampToken.
>=20
> Proposed change:=20
>    The serialNumber field is an integer assigned by the TSU to each
>    TimeStampToken.
>=20
> RFC 3161:
>    genTime is the time at which the time-stamp token has been created by
> =20
>    the TSA.
>=20
> Proposed change:
>    genTime is the time at which the time-stamp token has been created by
>    the TSU.
>=20
> RF3161:
>    The purpose of the tsa field is to give a hint in identifying the
>    name of the TSA.
>=20
> Proposed change:
>    The purpose of the tsu field is to give a hint in identifying the
>    name of the TSU.
>=20
> Note that the difference between a TSU and a TSA that is already present
> in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 1=
02
> 023.
> All these documents have been issued after RFC 3161.
>=20
> Even, if the bits on the wire are the same, the meaning of these bits
> would not necessarily be the same. For example, the ESSCertID refers to
> a  certificate from a TSU, not from a TSA.
>=20
> Since the changes to be done are scattered around the document, a new dra=
ft
> would seem more appropriate, hence why a new draft has been proposed.
>=20
> From another angle, should we have an update to RFC 3161 or a new draft?
> An update would have to advantage to keep the magic number 3161 that ever=
ybody
> identifies with TSP.
>=20
> In any case, I believe that both the ESSCertIDv2 and the terminology aspe=
cts
> should be addressed to align RFC 3161 with the documents issued after it.
>=20
> Denis
>> =20
>> -----  Message re=E7u -----
>> =20
>> De  : Stefan Santesson <mailto :[email-masked]>
>> =20
>> =C0  : Pope,Nick,ietf-pkix <mailto
>> :[email-masked],[email-masked]>
>> =20
>> Date  : 2009-07-09, 13:13:15
>> =20
>> Sujet  : Re: Way forward - updating RFC 3161
>> =20
>>=20
>> =20
>> =20
>> =20
>> I conclude that the list so far is unanimous in its  view of not accepti=
ng
>> the approach of draft-ietf-pkix-rfc3161bis-01.
>> Even  though we have not heard the opinion of the draft author, It feels=
 that
>> we  will have a strong consensus for just making a short update  documen=
t.
>>=20
>> /Stefan
>>=20
>>=20
>> On 09-07-01 12:47 PM, "Pope, Nick" <[email-masked]>  wro=
te:
>>=20
>> =20
>>> Stefan,
>>> =20
>>> I also agree with the approach  of updating RFC 3161.  Changing the mod=
el of
>>> RFC 3161 is only going to  cause confusion.
>>> =20
>>> The implementation architecture concepts used  in the earlier proposal =
are
>>> already described in RFC 3628  and so I see  no need for further steps =
on
>>> that  aspect.
>>> =20
>>> Nick
>>> =20
>>>=20
>>> Sent: 01 July 2009 02:00
>>> To: [email-masked]
>>> Cc: Denis Pinkas;  Pope, Nick
>>> Subject: Way forward - updating RFC  3161
>>>=20
>>> We  need to resolve how to update RFC 3161 with respect to allowing sup=
port
>>> of  RFC 5035 (ESSV2)
>>> One particular reason is because ETSI ESI is dependent  on progression =
of
>>> this issue in PKIX.
>>>=20
>>> I would like to open this issue  up for debate and then hopefully concl=
ude
>>> this issue, possibly after a straw  poll.
>>>=20
>>> My personal opinion, and what I interpret as the general  opinion of th=
is
>>> working group is that we should reject  draft-ietf-pkix-rfc3161bis-01 a=
s
>>> basis for updating rfc 3161. This draft  intends to obsolete RFC 3161 a=
nd
>>> introduces major changes to terminology and  role description to align =
RFC
>>> 3161 with the informational document RFC  3628.
>>>=20
>>> It is problematic to introduce such major changes to a standard  that i=
s
>>> widely deployed. It is neither required from a protocol  implementation
>>> perspective as these changes are not intended to change any  bits on th=
e
>>> wire. The optional usage of ESSV2 does not motivate a total  rewrite of=
 the
>>> current standard, but is better handled in an update  RFC.
>>>=20
>>> If description of roles and responsibilities that so not change  any bi=
ts on
>>> the wire need to be clarified in relation to RFC 3628 and RFC  3161, th=
en
>>> this should be handled either as an update to RFC 3628 or as a  separat=
e
>>> informational document.
>>>=20
>>> /Stefan =20
>>>=20
>=20

--B_3330859164_13106136
Content-type: text/html;
	charset="ISO-8859-1"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Way forward - updating RFC 3161</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>Denis,<BR>
<BR>
I have seen your response and waited to see if someone is stepping up to su=
pport you, but it seems that you are quite alone in your urge to update the =
terminology and role separation of the time stamping protocol.<BR>
<BR>
My primary issue is not whether the role separation is accurate and well mo=
tivated. The central issue for me is why it need to be included in the proto=
col specification.<BR>
Note that we have a very similar situation with PKI. The CA issues certific=
ates, but in practice the CA will delegate the signing to a &#8220;unit&#822=
1; and may delegate authorization of attributes to &nbsp;&#8220;Registration=
 Authority&#8221;. Still, the CA is ultimately the responsible party and not=
 any &#8220;unit&#8221; or other subordinate entity or process. The same is =
true for a TSA. The TSA is the responsible entity and as such the entity tha=
t is represented by the certificate of the service, even if that certificate=
 indicates which unit under the TSA control that actually signed the Time-st=
amp.<BR>
<BR>
As long as this does not reflect any bits on the wire, it would just be con=
fusing to define the role separation structure behind the service as part of=
 the protocol.<BR>
<BR>
This is where I think you have failed to convince us.<BR>
<BR>
Unless I hear new convincing arguments, I will treat the answers on this li=
st as a rough consensus decision to NOT make a full replacement of RFC 3161,=
 but merely provide an update document with ESSCertIDv2 and possibly similar=
 minor updates, but to drop alignment with RFC 3628 terminology.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
<BR>
On 09-07-10 3:55 PM, &quot;Denis Pinkas&quot; &lt;<a href=3D"denis.pinkas@bul=
l.net">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helve=
tica, Arial"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'>No doubt that everybody agrees that RFC 3161 should be updated to allow =
the use of RFC 5035 [ESSV2]. <BR>
The question is whether other changes should also be made.<BR>
<BR>
The major differences from RFC 3161 [RFC3161] are summarized on page 3 of t=
he draft and are listed below:<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;1 - the document has been aligned with RFC 36=
28 to make the <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;difference between a =
time-stamping unit (TSU) and a TSA.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2 - the document makes the difference between=
 a time-stamping <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service and a time-st=
amping unit and allows a time-stamping <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;service to support mo=
re than one time-stamping unit.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3 - the format of the subject field of a TSU =
certificate is now <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;defined.<BR>
<BR>
and also some minor updates :<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;4 - informative references to ISO 18014-1 [IS=
O18014-1], <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;ISO 18014-2 [ISO18014=
-2] and ISO 18014-3 [ISO18014-3] have been <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;added.<BR>
<BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;5 - a new normative ASN1 module to refer to t=
he ASN.1 modules <BR>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;from the latest RFCs.=
 <BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>At the moment, RFC 3161 makes confusion between three dif=
ferent concepts: <BR>
a TSA, a TSS and a TSU, respectively a Time-Stamping Authority, <BR>
a Time-Stamping Service and a Time-Stamping Unit. <BR>
</SPAN></FONT></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica,=
 Arial"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:10pt'><FONT FACE=3D"Courier New">IMO, th=
e document should be cleaned to call a spade a spade.<BR>
<BR>
Historically, the notions applicable to TSAs have been copied and pasted <B=
R>
from the documents related to CAs. Since a CA had one private key, a TSA <B=
R>
had one private key as well, but this was short looking.<BR>
<BR>
The CA advertises one public key, or more exactly one trust anchor, usually=
 <BR>
by issuing a self-signed certificate. This private key, when in use, <BR>
is supported by one HSH (Hardware Security Module). This private key needs =
<BR>
to be saved in order to be restored in case of a problem. The time for rest=
oration <BR>
is usually not critical (this may take a few minutes or even a few hours). =
<BR>
The life time of a CA certificate (or CA public key) is usually between one=
 and <BR>
15 years and should not be changed earlier, unless strictly needed.<BR>
<BR>
In order to provide time-stamp tokens (TSTs) with high availability, more t=
han <BR>
one TSU is usually needed. These units altogether provide a TSS (Time-Stamp=
ing Service) <BR>
that is managed by an Authority called a TSA (Time-Stamping Authority).<BR>
<BR>
The key used to sign TSTs is not the key from a TSA, but the key from a TSU=
.<BR>
<BR>
In order to a high level of security, the key used to sign to TSTs should N=
OT be saved <BR>
and restored. It should be generated by the TSU itself and should NOT be ex=
ported <BR>
outside the TSU. If the key of the TSU is erased purposely or by accident, =
a new key pair <BR>
and certificate should be generated. Since TSU certificates are provided by=
 a CA, <BR>
TST verification systems do not need to change any trust anchor. Some TSUs =
may even <BR>
use short-lived TSU certificates, e.g. a TSU certificate valid for one week=
 or even one day. <BR>
However, it is necessary to be able to know the name of the TSA when lookin=
g at the <BR>
subject DN from the TSU certificate.<BR>
<BR>
Along these lines, several changes should be made to RFC 3161. To mention a=
 few of them:<BR>
<BR>
RFC 3161:<BR>
</FONT></SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;If the TSA does not recognize the hash</SPAN><FONT SIZE=3D"2"=
><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;algorithm or knows =
that the hash algorithm is weak (a decision left</SPAN><FONT SIZE=3D"4"><SPAN =
STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to the discretion o=
f each individual TSA), then the TSA SHOULD refuse</SPAN><FONT SIZE=3D"4"><SPA=
N STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to provide the time=
-stamp token by returning a pkiStatusInfo of</SPAN><FONT SIZE=3D"4"><SPAN STYL=
E=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;'bad_alg'.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Proposed change :<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;If the TSS does not recognize the hash</SPAN><FONT SIZE=3D"4"=
><SPAN STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;algorithm or knows =
that the hash algorithm is weak (a decision left</SPAN><FONT SIZE=3D"4"><SPAN =
STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to the discre=
tion of each individual TSA), then the TSS SHOULD refuse</SPAN><FONT SIZE=3D"2=
"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT><S=
PAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;to provide the time-stamp token by r=
eturning a pkiStatusInfo of</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt=
'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT><S=
PAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;'bad_alg'.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>RFC3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The certificate identifier (ESSCertID) of the</SPAN><FONT S=
IZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;TSA certificate MUS=
T be included as a signerInfo attribute inside a</SPAN><FONT SIZE=3D"2"><SPAN =
STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> &nbsp;</SPAN></F=
ONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'>SigningCertificate attribute=
.<BR>
<BR>
Proposed change:<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;The certificate ide=
ntifier (either ESSCertID &nbsp;or ESSCertIDv2) of the TSU certificate <BR>
&nbsp;&nbsp;MUST be included as a </SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"=
Courier New"><SPAN STYLE=3D'font-size:10pt'>signerInfo attribute inside a Sign=
ingCertificate attribute.<BR>
<BR>
RFC 3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The serialNumber field is an integer assigned by the TSA to=
 each</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT></=
FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-size:10pt'> T=
imeStampToken.<BR>
<BR>
Proposed change: <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The serialNumber field is an integer assigned by the TSU to=
 each</SPAN><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> </SPAN></FONT><S=
PAN STYLE=3D'font-size:12pt'> &nbsp;TimeStampToken.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>RFC 3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;genTime is the time at which the time-stamp token has been =
created by</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;<BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;the TSA.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Proposed change:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;genTime is the time at which the time-stamp token has been =
created by</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;the TSU.<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>RF3161:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The purpose of the tsa field is to give a hint in identifyi=
ng the</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
&nbsp;</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;name of the TSA.<BR=
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Proposed change:<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;&nbsp;The purpose of the tsu field is to give a hint in identifyi=
ng the</SPAN><FONT SIZE=3D"4"><SPAN STYLE=3D'font-size:14pt'> <BR>
</SPAN></FONT><SPAN STYLE=3D'font-size:12pt'> &nbsp;&nbsp;name of the TSU.<BR=
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'font-siz=
e:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Note that the difference between a TSU and a TSA that is =
already present <BR>
in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 102=
 023.<BR>
All these documents have been issued after RFC 3161.<BR>
<BR>
Even, if the bits on the wire are the same, the meaning of these bits <BR>
would not necessarily be the same. For example, the ESSCertID refers to <BR=
a &nbsp;certificate from a TSU, not from a TSA.<BR>
<BR>
Since the changes to be done are scattered around the document, a new draft=
 <BR>
would seem more appropriate, hence why a new draft has been proposed.<BR>
<BR>
>From another angle, should we have an update to RFC 3161 or a new draft? <B=
R>
An update would have to advantage to keep the magic number 3161 that everyb=
ody <BR>
identifies with TSP.<BR>
<BR>
In any case, I believe that both the ESSCertIDv2 and the terminology aspect=
s <BR>
should be addressed to align RFC 3161 with the documents issued after it. <=
BR>
</SPAN></FONT></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Courier New"><SPAN STYLE=3D'f=
ont-size:10pt'><BR>
</SPAN></FONT></FONT><FONT SIZE=3D"4"><FONT FACE=3D"Times New Roman"><SPAN STYL=
E=3D'font-size:14pt'>Denis<BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana=
, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT></FONT><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"><FONT S=
IZE=3D"1"><SPAN STYLE=3D'font-size:9pt'>----- &nbsp;Message re&ccedil;u ----- <B=
R>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>De &nbsp;:</B> =
Stefan Santesson &lt;mailto :<a href=3D"[email-masked]">[email-masked]=
</a>&gt; &nbsp;<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>&Agrave; &nbsp;=
:</B> Pope,Nick,ietf-pkix &lt;mailto :<a href=3D"[email-masked]=
m">[email-masked]</a>,<a href=3D"[email-masked]">ietf-pkix@=
imc.org</a>&gt; &nbsp;&nbsp;<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>Date &nbsp;:</B=
> 2009-07-09, 13:13:15<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT><FONT SIZE=3D"1"><SPAN STYLE=3D'font-size:9pt'><B>Sujet &nbsp;:</=
B> Re: Way forward - updating RFC 3161<BR>
</SPAN></FONT><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt'> <BR>
<BR>
&nbsp;<BR>
&nbsp;<BR>
&nbsp;<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN =
STYLE=3D'font-size:11pt'>I conclude that the list so far is unanimous in its &=
nbsp;view of not accepting the approach of draft-ietf-pkix-rfc3161bis-01.<BR=
Even &nbsp;though we have not heard the opinion of the draft author, It fee=
ls that we &nbsp;will have a strong consensus for just making a short update=
 &nbsp;document.<BR>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-01 12:47 PM, &quot;Pope, Nick&quot; &lt;<a href=3D"Nick.Pope@thales-=
esecurity.com">[email-masked]</a>&gt; &nbsp;wrote:<BR>
<BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'> <BR>
</SPAN></FONT></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><SPAN STYLE=3D'font-size:10pt=
'><FONT COLOR=3D"#000080"><FONT FACE=3D"Arial">Stefan,<BR>
&nbsp;<BR>
I also agree with the approach &nbsp;of updating RFC 3161. &nbsp;Changing t=
he model of RFC 3161 is only going to &nbsp;cause confusion.<BR>
&nbsp;<BR>
The implementation architecture concepts used &nbsp;in the earlier proposal=
 are already described in RFC 3628 &nbsp;and so I see &nbsp;no need for furt=
her steps on that &nbsp;aspect.<BR>
&nbsp;<BR>
Nick<BR>
&nbsp;<BR>
</FONT></FONT></SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'>-----Original Message-----<BR>
<B>From:</B> Stefan &nbsp;Santesson [<a href=3D"mailto:[email-masked]">ma=
ilto:[email-masked]</a>] &nbsp;<BR>
<B>Sent:</B> 01 July 2009 02:00<BR>
<B>To:</B> <a href=3D"[email-masked]">[email-masked]</a><BR>
<B>Cc:</B> Denis Pinkas; &nbsp;Pope, Nick<BR>
<B>Subject:</B> Way forward - updating RFC &nbsp;3161<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'><BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>We &nbsp;need to resolve how to update RFC 3161 with respect=
 to allowing support of &nbsp;RFC 5035 (ESSV2)<BR>
One particular reason is because ETSI ESI is dependent &nbsp;on progression=
 of this issue in PKIX.<BR>
<BR>
I would like to open this issue &nbsp;up for debate and then hopefully conc=
lude this issue, possibly after a straw &nbsp;poll.<BR>
<BR>
My personal opinion, and what I interpret as the general &nbsp;opinion of t=
his working group is that we should reject &nbsp;draft-ietf-pkix-rfc3161bis-=
01 as basis for updating rfc 3161. This draft &nbsp;intends to obsolete RFC =
3161 and introduces major changes to terminology and &nbsp;role description =
to align RFC 3161 with the informational document RFC &nbsp;3628.<BR>
<BR>
It is problematic to introduce such major changes to a standard &nbsp;that =
is widely deployed. It is neither required from a protocol &nbsp;implementat=
ion perspective as these changes are not intended to change any &nbsp;bits o=
n the wire. The optional usage of ESSV2 does not motivate a total &nbsp;rewr=
ite of the current standard, but is better handled in an update &nbsp;RFC.<B=
R>
<BR>
If description of roles and responsibilities that so not change &nbsp;any b=
its on the wire need to be clarified in relation to RFC 3628 and RFC &nbsp;3=
161, then this should be handled either as an update to RFC 3628 or as a &nb=
sp;separate informational document.<BR>
<BR>
/Stefan</SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> &nbsp;<BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE></BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, =
Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:10pt'><BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3330859164_13106136--

Date: Wed, 15 Jul 2009 11:56:16 -0400
From: Massimiliano Pala <[email-masked]>
Organization: Dartmouth College - Computer Science Department
To: Jean-Marc Desperrier <[email-masked]>
CC: pkix <[email-masked]>
Subject: Re: RFC5280 : Applications and CRL DP extension support
X-Dartmouth.EDU-MailScanner-Information: Please contact the ISP for more information
X-Dartmouth.EDU-MailScanner-ID: n6FFIXHW019713
X-MailScanner: Found to be clean by mailhub21.dartmouth.edu
X-MailScanner-From: [email-masked]
Sender: [email-masked]
Precedence: bulk
List-Archive: <http://www.imc.org/ietf-pkix/mail-archive/>
List-ID: <ietf-pkix.imc.org>
List-Unsubscribe: <mailto:[email-masked]?body=unsubscribe>

This is a cryptographically signed message in MIME format.

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

Hi Jean,

your pledge for more dynamic approach to CRLs (but this could be applied
to any URLs embedded into certificates) is well known. Take a look at PRQP
(PKI Resource Query Protocol), currently a draft (you can download it
from the PKIX WG page): this should provide a solution to that by having
an authoritative source of information (instead of having just a
"configuration" file).

Hope this will help,

Best,
Max

Jean-Marc Desperrier wrote:
> 
> The text of RFC5280 says :
> 4.2.1.14 CRL Distribution Points
>     [...] this profile
>     recommends support for this extension by CAs and applications.
> 
> Whilst I 100% approve the recommendation for CAs (No CA should issue 
> certificates without CRLDP when they do provide CRL), what does it in 
> practice mean for applications ?
> 
> They are cases where dynamically  downloading the CRL by interpreting 
> the CRL DP extension is inappropriate for some applications, and where 
> the needs and context of the application make it much more adequate to 
> instead to configure in advance the location where the CRL of the 
> supported CAs can be found.
> 
> Some examples  :
> - Closed networks : Network access to the open internet and the CRL DP 
> might be simply unavailable, and the application should get CRLs from 
> copies made at alternative locations on the local network.
> - Controled network : Even if no alternative local location is provided, 
> network rules may forbid network  access that has not been vetted 
> beforehand, so make it inappropriate if the application tries to 
> download data from a location based on the information contained in any 
> the certificate it just received
> - Performance : When the application has to validate a hich volume of 
> certificates, dynamic loading of the CRL is simply inappropriate. This 
> can be worked around by using caching mechanisms, but it will be more 
> adequate to use configuration particularly if the application already 
> configures rules about how often to download new CRLs (CRLS quite often 
> are renewed more frequently than their nextUpdate field signals, some CA 
> renew their CRL every day, but have a nextUpdate filed valid for one week).
> 
> So whilst it's very useful to have the CA include the information inside 
> the certificate, I think the standard should not try to constrain the 
> methods by which the application will get it's up to date revocation 
> info, or make it clearer that the use of alternates is appropriate when 
> they will give the same result.
> 
> Can I have confirmation from the group that the text in RFC5280 is *not* 
> intended to discourage applications under such circumstances from using 
> configuration settings instead of dynamically reading the CRL DP 
> extension content  ?
> 
> 
> 

-- 

Best Regards,

	Massimiliano Pala

--o------------------------------------------------------------------------
Massimiliano Pala [OpenCA Project Manager]  [email-masked]
                                                  [email-masked]

Dartmouth Computer Science Dept               Home Phone: +1 (603) 369-9332
PKI/Trust Laboratory                          Work Phone: +1 (603) 646-9179
--o------------------------------------------------------------------------

People who think they know everything are a great annoyance to those of us
who do.
							   -- Isaac Asimov

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

--------------ms030509070506050206060504--

Date: Wed, 15 Jul 2009 17:51:14 +0200
From: Peter Sylvester <[email-masked]>
To: Jean-Marc Desperrier <[email-masked]>
Cc: [email-masked]
Subject: Re: RFC5280 : Applications and CRL DP extension support
Sender: [email-masked]

Jean-Marc Desperrier wrote:
>
> The text of RFC5280 says :
> 4.2.1.14 CRL Distribution Points
>     [...] this profile
>     recommends support for this extension by CAs and applications.
the full text is:

 The CRL distribution points extension identifies how CRL information
   is obtained.  The extension SHOULD be non-critical, but this profile
   RECOMMENDS support for this extension by CAs and applications.

>
> Whilst I 100% approve the recommendation for CAs (No CA should issue 
> certificates without CRLDP when they do provide CRL),
It is a recommandation, but not a requirement. Why do you approve the 
recommandation?

> what does it in practice mean for applications ?
>
>
> They are cases where dynamically  downloading the CRL by interpreting 
> the CRL DP extension is inappropriate for some applications, and where 
> the needs and context of the application make it much more adequate to 
> instead to configure in advance the location where the CRL of the 
> supported CAs can be found.
it depends what you mean by "dynamically". If you say: immediately, 
instantaneously, or during path
validation, then I agree with you. a relying party should  not be 
required to have a working
network connection to an uncontrollable environment.

The first sentence coul  probably be enhanced to read:
 "can be obtained", or "where the CA publishes a CRL for this cert"
>
> Some examples  :
> - Closed networks : Network access to the open internet and the CRL DP 
> might be simply unavailable, and the application should get CRLs from 
> copies made at alternative locations on the local network.
> - Controled network : Even if no alternative local location is 
> provided, network rules may forbid network  access that has not been 
> vetted beforehand, so make it inappropriate if the application tries 
> to download data from a location based on the information contained in 
> any the certificate it just received
> - Performance : When the application has to validate a hich volume of 
> certificates, dynamic loading of the CRL is simply inappropriate. This 
> can be worked around by using caching mechanisms, but it will be more 
> adequate to use configuration particularly if the application already 
> configures rules about how often to download new CRLs (CRLS quite 
> often are renewed more frequently than their nextUpdate field signals, 
> some CA renew their CRL every day, but have a nextUpdate filed valid 
> for one week).
The CA defines in its policy the source of CRLs. It also defines what 
kind of relying parties are possible.
If the a relying party is not able to use a "correct" crldp pointer due 
the first two cases, then one of the
parties hasn't done its job. resolving the url may also lead to 
different physical servers

performance: a local OCSP validation server (one of the first kind) can 
be regarded as just such a cache.
Unfortunately, the server cannot really "learn", because it never 
actually sees a certificate.

>
>
> So whilst it's very useful to have the CA include the information 
> inside the certificate, I think the standard should not try to 
> constrain the methods by which the application will get it's up to 
> date revocation info, or make it clearer that the use of alternates is 
> appropriate when they will give the same result.
The standard doesn't constrain this IMO. A recommandation is not a MUST.

>
>
> Can I have confirmation from the group that the text in RFC5280 is 
> *not* intended to discourage applications under such circumstances 
> from using configuration settings instead of dynamically reading the 
> CRL DP extension content  ?
>
>
The standard doesn't say that you have to get the information in a 
"dynamic" way IMO. loading crls
from a file which is updated in intervals is an implementation detail 
for a relying party.
I would thus vote: 'confirmed'.

Date: Wed, 15 Jul 2009 16:02:53 +0200
From: Jean-Marc Desperrier <[email-masked]>
To: [email-masked]
Subject: RFC5280 : Applications and CRL DP extension support
Sender: [email-masked]

The text of RFC5280 says :
4.2.1.14 CRL Distribution Points
     [...] this profile
     recommends support for this extension by CAs and applications.

Whilst I 100% approve the recommendation for CAs (No CA should issue 
certificates without CRLDP when they do provide CRL), what does it in 
practice mean for applications ?

They are cases where dynamically  downloading the CRL by interpreting 
the CRL DP extension is inappropriate for some applications, and where 
the needs and context of the application make it much more adequate to 
instead to configure in advance the location where the CRL of the 
supported CAs can be found.

Some examples  :
- Closed networks : Network access to the open internet and the CRL DP 
might be simply unavailable, and the application should get CRLs from 
copies made at alternative locations on the local network.
- Controled network : Even if no alternative local location is provided, 
network rules may forbid network  access that has not been vetted 
beforehand, so make it inappropriate if the application tries to 
download data from a location based on the information contained in any 
the certificate it just received
- Performance : When the application has to validate a hich volume of 
certificates, dynamic loading of the CRL is simply inappropriate. This 
can be worked around by using caching mechanisms, but it will be more 
adequate to use configuration particularly if the application already 
configures rules about how often to download new CRLs (CRLS quite often 
are renewed more frequently than their nextUpdate field signals, some CA 
renew their CRL every day, but have a nextUpdate filed valid for one week).

So whilst it's very useful to have the CA include the information inside 
the certificate, I think the standard should not try to constrain the 
methods by which the application will get it's up to date revocation 
info, or make it clearer that the use of alternates is appropriate when 
they will give the same result.

Can I have confirmation from the group that the text in RFC5280 is *not* 
intended to discourage applications under such circumstances from using 
configuration settings instead of dynamically reading the CRL DP 
extension content  ?

From: "Pope, Nick" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, Carl Wallace <[email-masked]>, [email-masked], [email-masked]
Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Wed, 15 Jul 2009 10:24:39 +0100
Sender: [email-masked]

All,

I accept that we may not be able to change at this stage the TAF but we both
should bear in mind the existence the two solutions which need exist
together.

Nick

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Stefan Santesson
> Sent: 15 July 2009 02:16
> To: Carl Wallace; Pope, Nick; [email-masked]; [email-masked]
> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
> Proposed Standard
> 
> 
> Carl,
> 
> I agree with most of your assessment.
> 
> But Yes, there are interoperability issues on the larger scale.
> One current example is for example that the European and American Bridging
> CA models are incompatible from a technical perspective as the American
> model builds on cross certification while the European model builds on
> availability of TSLs.
> 
> A potential real impact scenario is that products may have to incorporate
> both architectures in order to function in both worlds. That is something
> I
> as standards guy would be pleased to avoid.
> 
> However, I don't think there is much we neither can or should do to change
> this.
> 
> 
> On 09-07-15 2:46 AM, "Carl Wallace" <[email-masked]> wrote:
> 
> >
> > TAF works with existing systems that use certificates as trust anchors
> > (a certificate is a TrustAnchorChoice object), offers a minor change to
> > that practice to allow relying parties to associate constraints with
> > certificates using syntax that is widely available (TBSCertificate) and
> > offers a minimal representation of trust anchor information for folks
> > who require such (TrustAnchorInfo).  I don't see an interoperability
> > issue with TAF.  Applications will use the appropriate format that meets
> > its needs.  Certificates are not suitable as trust anchors in all cases.
> > TAF is a relatively minimal, natural solution to this problem.
> >
> >
> >> Sent: Tuesday, July 14, 2009 6:42 PM
> >> To: Carl Wallace; Pope, Nick; [email-masked]; [email-masked]
> >> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >> to Proposed Standard
> >>
> >> Carl,
> >>
> >> I think the critique of the TSL work is well founded from the
> >> perspective of
> >> TAM, but there is nevertheless an important point here.
> >>
> >> While TSL might not be an ideal standard for automated trust anchor
> >> management, very much caused by its mixed scope of fields for both
> >> human and
> >> machine consumption, it has despite this become a central component
> > for
> >> efforts in Europe, supported by the EU commission, to provide a common
> >> framework for trust in CAs in Europe.
> >>
> >> There is a substantial risk that we will see two very different
> >> approaches
> >> that at least overlap in scope, which may harm interoperability.
> >>
> >> /Stefan
> >>
> >>
> >>
> >> On 09-07-10 1:50 PM, "Carl Wallace" <[email-masked]> wrote:
> >>
> >>> This document has been discussed previously relative to TAF.  A
> >> portion
> >>> of that discussion is here:
> >>> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> >>>
> >>>
> >>>> [email-masked]] On Behalf Of Pope, Nick
> >>>> Sent: Friday, July 10, 2009 4:02 AM
> >>>> To: [email-masked]'; [email-masked]
> >>>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> >>> Format)
> >>>> to Proposed Standard
> >>>>
> >>>>
> >>>> Perhaps the authors should be aware of the existing European
> >> Technical
> >>>> Specification for trust status lists (TS 102 231), which have some
> >>>> overlap
> >>>> in function with the Trust anchor list in this internet draft.
> >>>>
> >>>> This is being adopted by all EU member states as a means of
> >> publishing
> >>>> information on CA recognised as trustworthy under the national
> >>>> accreditation
> >>>> or supervisory schemes.
> >>>>
> >>>> To obtain a copy go to:
> >>>>
> >>>> http://pda.etsi.org/pda/queryform.asp
> >>>>
> >>>> and enter TS 102 231 in the search box.
> >>>>
> >>>> Nick Pope
> >>>> Thales e-Security Ltd
> >>>>
> >>>>
> >>>>
> >>>> [email-masked]]
> >>>>> On Behalf Of The IESG
> >>>>> Sent: 10 July 2009 01:14
> >>>>> To: IETF-Announce
> >>>>> Cc: [email-masked]
> >>>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >>>> to
> >>>>> Proposed Standard
> >>>>>
> >>>>>
> >>>>> The IESG has received a request from the Public-Key Infrastructure
> >>>>> (X.509) WG (pkix) to consider the following document:
> >>>>>
> >>>>> - 'Trust Anchor Format '
> >>>>>    <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard
> >>>>>
> >>>>> The IESG plans to make a decision in the next few weeks, and
> >>> solicits
> >>>>> final comments on this action.  Please send substantive comments
> > to
> >>>> the
> >>>>> [email-masked] mailing lists by 2009-07-23. Exceptionally,
> >>>>> comments may be sent to [email-masked] instead. In either case,
> >>> please
> >>>>> retain the beginning of the Subject line to allow automated
> >> sorting.
> >>>>>
> >>>>> The file can be obtained via
> >>>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-
> >> 03.txt
> >>>>>
> >>>>>
> >>>>> IESG discussion can be tracked via
> >>>>>
> >>>>
> >>>
> >>
> > https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
> >>>> =17
> >>>>> 759&rfc_flag=0
> >>>> Consider the environment before printing this mail.
> >>>> "Thales e-Security Limited is incorporated in England and Wales
> > with
> >>>> company
> >>>> registration number 2518805. Its registered office is located at 2
> >>>> Dashwood
> >>>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
> >> Surrey
> >>>> KT15
> >>>> 2NX.
> >>>> The information contained in this e-mail is confidential. It may
> >> also
> >>>> be
> >>>> privileged. It is only intended for the stated addressee(s) and
> >> access
> >>>> to it
> >>>> by any other person is unauthorised. If you are not an addressee or
> >>> the
> >>>> intended addressee, you must not disclose, copy, circulate or in
> > any
> >>>> other
> >>>> way use or rely on the information contained in this e-mail. Such
> >>>> unauthorised use may be unlawful. If you have received this e-mail
> >> in
> >>>> error
> >>>> please delete it (and all copies) from your system, please also
> >> inform
> >>>> us
> >>>> immediately on +44 (0)1844 201800 or email postmaster@thales-
> >>>> esecurity.com.
> >>>> Commercial matters detailed or referred to in this e-mail are
> >> subject
> >>>> to a
> >>>> written contract signed for and on behalf of Thales e-Security
> >>>> Limited".
> >>>
> >>> _______________________________________________
> >>> Ietf mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/ietf
> >>
> >

Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

Date: Wed, 15 Jul 2009 03:15:30 +0200
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
From: Stefan Santesson <[email-masked]>
To: Carl Wallace <[email-masked]>, "Pope, Nick" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Carl,

I agree with most of your assessment.

But Yes, there are interoperability issues on the larger scale.
One current example is for example that the European and American Bridging
CA models are incompatible from a technical perspective as the American
model builds on cross certification while the European model builds on
availability of TSLs.

A potential real impact scenario is that products may have to incorporate
both architectures in order to function in both worlds. That is something I
as standards guy would be pleased to avoid.

However, I don't think there is much we neither can or should do to change
this.

On 09-07-15 2:46 AM, "Carl Wallace" <[email-masked]> wrote:

> 
> TAF works with existing systems that use certificates as trust anchors
> (a certificate is a TrustAnchorChoice object), offers a minor change to
> that practice to allow relying parties to associate constraints with
> certificates using syntax that is widely available (TBSCertificate) and
> offers a minimal representation of trust anchor information for folks
> who require such (TrustAnchorInfo).  I don't see an interoperability
> issue with TAF.  Applications will use the appropriate format that meets
> its needs.  Certificates are not suitable as trust anchors in all cases.
> TAF is a relatively minimal, natural solution to this problem.
> 
> 
>> Sent: Tuesday, July 14, 2009 6:42 PM
>> To: Carl Wallace; Pope, Nick; [email-masked]; [email-masked]
>> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> Format)
>> to Proposed Standard
>> 
>> Carl,
>> 
>> I think the critique of the TSL work is well founded from the
>> perspective of
>> TAM, but there is nevertheless an important point here.
>> 
>> While TSL might not be an ideal standard for automated trust anchor
>> management, very much caused by its mixed scope of fields for both
>> human and
>> machine consumption, it has despite this become a central component
> for
>> efforts in Europe, supported by the EU commission, to provide a common
>> framework for trust in CAs in Europe.
>> 
>> There is a substantial risk that we will see two very different
>> approaches
>> that at least overlap in scope, which may harm interoperability.
>> 
>> /Stefan
>> 
>> 
>> 
>> On 09-07-10 1:50 PM, "Carl Wallace" <[email-masked]> wrote:
>> 
>>> This document has been discussed previously relative to TAF.  A
>> portion
>>> of that discussion is here:
>>> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
>>> 
>>> 
>>>> [email-masked]] On Behalf Of Pope, Nick
>>>> Sent: Friday, July 10, 2009 4:02 AM
>>>> To: [email-masked]'; [email-masked]
>>>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
>>> Format)
>>>> to Proposed Standard
>>>> 
>>>> 
>>>> Perhaps the authors should be aware of the existing European
>> Technical
>>>> Specification for trust status lists (TS 102 231), which have some
>>>> overlap
>>>> in function with the Trust anchor list in this internet draft.
>>>> 
>>>> This is being adopted by all EU member states as a means of
>> publishing
>>>> information on CA recognised as trustworthy under the national
>>>> accreditation
>>>> or supervisory schemes.
>>>> 
>>>> To obtain a copy go to:
>>>> 
>>>> http://pda.etsi.org/pda/queryform.asp
>>>> 
>>>> and enter TS 102 231 in the search box.
>>>> 
>>>> Nick Pope
>>>> Thales e-Security Ltd
>>>> 
>>>> 
>>>> 
>>>> [email-masked]]
>>>>> On Behalf Of The IESG
>>>>> Sent: 10 July 2009 01:14
>>>>> To: IETF-Announce
>>>>> Cc: [email-masked]
>>>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> Format)
>>>> to
>>>>> Proposed Standard
>>>>> 
>>>>> 
>>>>> The IESG has received a request from the Public-Key Infrastructure
>>>>> (X.509) WG (pkix) to consider the following document:
>>>>> 
>>>>> - 'Trust Anchor Format '
>>>>>    <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard
>>>>> 
>>>>> The IESG plans to make a decision in the next few weeks, and
>>> solicits
>>>>> final comments on this action.  Please send substantive comments
> to
>>>> the
>>>>> [email-masked] mailing lists by 2009-07-23. Exceptionally,
>>>>> comments may be sent to [email-masked] instead. In either case,
>>> please
>>>>> retain the beginning of the Subject line to allow automated
>> sorting.
>>>>> 
>>>>> The file can be obtained via
>>>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-
>> 03.txt
>>>>> 
>>>>> 
>>>>> IESG discussion can be tracked via
>>>>> 
>>>> 
>>> 
>> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>>>> =17
>>>>> 759&rfc_flag=0
>>>> Consider the environment before printing this mail.
>>>> "Thales e-Security Limited is incorporated in England and Wales
> with
>>>> company
>>>> registration number 2518805. Its registered office is located at 2
>>>> Dashwood
>>>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
>> Surrey
>>>> KT15
>>>> 2NX.
>>>> The information contained in this e-mail is confidential. It may
>> also
>>>> be
>>>> privileged. It is only intended for the stated addressee(s) and
>> access
>>>> to it
>>>> by any other person is unauthorised. If you are not an addressee or
>>> the
>>>> intended addressee, you must not disclose, copy, circulate or in
> any
>>>> other
>>>> way use or rely on the information contained in this e-mail. Such
>>>> unauthorised use may be unlawful. If you have received this e-mail
>> in
>>>> error
>>>> please delete it (and all copies) from your system, please also
>> inform
>>>> us
>>>> immediately on +44 (0)1844 201800 or email postmaster@thales-
>>>> esecurity.com.
>>>> Commercial matters detailed or referred to in this e-mail are
>> subject
>>>> to a
>>>> written contract signed for and on behalf of Thales e-Security
>>>> Limited".
>>> 
>>> _______________________________________________
>>> Ietf mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/ietf
>> 
> 

Content-class: urn:content-classes:message
Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Tue, 14 Jul 2009 20:46:38 -0400
From: "Carl Wallace" <[email-masked]>
To: "Stefan Santesson" <[email-masked]>, "Pope, Nick" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

TAF works with existing systems that use certificates as trust anchors
(a certificate is a TrustAnchorChoice object), offers a minor change to
that practice to allow relying parties to associate constraints with
certificates using syntax that is widely available (TBSCertificate) and
offers a minimal representation of trust anchor information for folks
who require such (TrustAnchorInfo).  I don't see an interoperability
issue with TAF.  Applications will use the appropriate format that meets
its needs.  Certificates are not suitable as trust anchors in all cases.
TAF is a relatively minimal, natural solution to this problem.   =20

> Sent: Tuesday, July 14, 2009 6:42 PM
> To: Carl Wallace; Pope, Nick; [email-masked]; [email-masked]
> Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
Format)
> to Proposed Standard
>=20
> Carl,
>=20
> I think the critique of the TSL work is well founded from the
> perspective of
> TAM, but there is nevertheless an important point here.
>=20
> While TSL might not be an ideal standard for automated trust anchor
> management, very much caused by its mixed scope of fields for both
> human and
> machine consumption, it has despite this become a central component
for
> efforts in Europe, supported by the EU commission, to provide a common
> framework for trust in CAs in Europe.
>=20
> There is a substantial risk that we will see two very different
> approaches
> that at least overlap in scope, which may harm interoperability.
>=20
> /Stefan
>=20
>=20
>=20
> On 09-07-10 1:50 PM, "Carl Wallace" <[email-masked]> wrote:
>=20
> > This document has been discussed previously relative to TAF.  A
> portion
> > of that discussion is here:
> > http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> >
> >
> >> [email-masked]] On Behalf Of Pope, Nick
> >> Sent: Friday, July 10, 2009 4:02 AM
> >> To: [email-masked]'; [email-masked]
> >> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> > Format)
> >> to Proposed Standard
> >>
> >>
> >> Perhaps the authors should be aware of the existing European
> Technical
> >> Specification for trust status lists (TS 102 231), which have some
> >> overlap
> >> in function with the Trust anchor list in this internet draft.
> >>
> >> This is being adopted by all EU member states as a means of
> publishing
> >> information on CA recognised as trustworthy under the national
> >> accreditation
> >> or supervisory schemes.
> >>
> >> To obtain a copy go to:
> >>
> >> http://pda.etsi.org/pda/queryform.asp
> >>
> >> and enter TS 102 231 in the search box.
> >>
> >> Nick Pope
> >> Thales e-Security Ltd
> >>
> >>
> >>
> >> [email-masked]]
> >>> On Behalf Of The IESG
> >>> Sent: 10 July 2009 01:14
> >>> To: IETF-Announce
> >>> Cc: [email-masked]
> >>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
Format)
> >> to
> >>> Proposed Standard
> >>>
> >>>
> >>> The IESG has received a request from the Public-Key Infrastructure
> >>> (X.509) WG (pkix) to consider the following document:
> >>>
> >>> - 'Trust Anchor Format '
> >>>    <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard
> >>>
> >>> The IESG plans to make a decision in the next few weeks, and
> > solicits
> >>> final comments on this action.  Please send substantive comments
to
> >> the
> >>> [email-masked] mailing lists by 2009-07-23. Exceptionally,
> >>> comments may be sent to [email-masked] instead. In either case,
> > please
> >>> retain the beginning of the Subject line to allow automated
> sorting.
> >>>
> >>> The file can be obtained via
> >>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-
> 03.txt
> >>>
> >>>
> >>> IESG discussion can be tracked via
> >>>
> >>
> >
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=

> >> =3D17
> >>> 759&rfc_flag=3D0
> >> Consider the environment before printing this mail.
> >> "Thales e-Security Limited is incorporated in England and Wales
with
> >> company
> >> registration number 2518805. Its registered office is located at 2
> >> Dashwood
> >> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge,
> Surrey
> >> KT15
> >> 2NX.
> >> The information contained in this e-mail is confidential. It may
> also
> >> be
> >> privileged. It is only intended for the stated addressee(s) and
> access
> >> to it
> >> by any other person is unauthorised. If you are not an addressee or
> > the
> >> intended addressee, you must not disclose, copy, circulate or in
any
> >> other
> >> way use or rely on the information contained in this e-mail. Such
> >> unauthorised use may be unlawful. If you have received this e-mail
> in
> >> error
> >> please delete it (and all copies) from your system, please also
> inform
> >> us
> >> immediately on +44 (0)1844 201800 or email postmaster@thales-
> >> esecurity.com.
> >> Commercial matters detailed or referred to in this e-mail are
> subject
> >> to a
> >> written contract signed for and on behalf of Thales e-Security
> >> Limited".
> >
> > _______________________________________________
> > Ietf mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/ietf
>=20

Date: Wed, 15 Jul 2009 02:16:29 +0200
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
From: Stefan Santesson <[email-masked]>
To: Paul Hoffman <[email-masked]>
CC: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Paul,

I just provided information.

I don't think we can do anything. It is not reasonable for IETF to accept
TSL as bases for our work and it is not possible to turn EU around and
abandon TSL.

However, it has a value to be aware of the situation.

/Stefan

On 09-07-15 1:49 AM, "Paul Hoffman" <[email-masked]> wrote:

> 
> At 12:42 AM +0200 7/15/09, Stefan Santesson wrote:
>> There is a substantial risk that we will see two very different approaches
>> that at least overlap in scope, which may harm interoperability.
> 
> And....?
> 
> Are you proposing that the IETF abandon its efforts because of the EU's? Or
> that the EU abandon its work because of the IETF's? Or that the two dissimilar
> protocols somehow be merged (in a way that would cause less, not greater,
> confusion)? Or something else?
> 
> This is IETF Last Call. Please say what you think should happen in the IETF
> context with respect to this document.
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 

Date: Tue, 14 Jul 2009 16:49:43 -0700
To: Stefan Santesson <[email-masked]>
From: Paul Hoffman <[email-masked]>
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Cc: <[email-masked]>, <[email-masked]>
Sender: [email-masked]

At 12:42 AM +0200 7/15/09, Stefan Santesson wrote:
>There is a substantial risk that we will see two very different approaches
>that at least overlap in scope, which may harm interoperability.

And....?

Are you proposing that the IETF abandon its efforts because of the EU's? Or that the EU abandon its work because of the IETF's? Or that the two dissimilar protocols somehow be merged (in a way that would cause less, not greater, confusion)? Or something else?

This is IETF Last Call. Please say what you think should happen in the IETF context with respect to this document.

--Paul Hoffman, Director
--VPN Consortium

Date: Wed, 15 Jul 2009 00:42:28 +0200
Subject: Re: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
From: Stefan Santesson <[email-masked]>
To: Carl Wallace <[email-masked]>, "Pope, Nick" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

Carl,

I think the critique of the TSL work is well founded from the perspective of
TAM, but there is nevertheless an important point here.

While TSL might not be an ideal standard for automated trust anchor
management, very much caused by its mixed scope of fields for both human and
machine consumption, it has despite this become a central component for
efforts in Europe, supported by the EU commission, to provide a common
framework for trust in CAs in Europe.

There is a substantial risk that we will see two very different approaches
that at least overlap in scope, which may harm interoperability.

/Stefan

On 09-07-10 1:50 PM, "Carl Wallace" <[email-masked]> wrote:

> This document has been discussed previously relative to TAF.  A portion
> of that discussion is here:
> http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.
> 
> 
>> [email-masked]] On Behalf Of Pope, Nick
>> Sent: Friday, July 10, 2009 4:02 AM
>> To: [email-masked]'; [email-masked]
>> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
> Format)
>> to Proposed Standard
>> 
>> 
>> Perhaps the authors should be aware of the existing European Technical
>> Specification for trust status lists (TS 102 231), which have some
>> overlap
>> in function with the Trust anchor list in this internet draft.
>> 
>> This is being adopted by all EU member states as a means of publishing
>> information on CA recognised as trustworthy under the national
>> accreditation
>> or supervisory schemes.
>> 
>> To obtain a copy go to:
>> 
>> http://pda.etsi.org/pda/queryform.asp
>> 
>> and enter TS 102 231 in the search box.
>> 
>> Nick Pope
>> Thales e-Security Ltd
>> 
>> 
>> 
>> [email-masked]]
>>> On Behalf Of The IESG
>>> Sent: 10 July 2009 01:14
>>> To: IETF-Announce
>>> Cc: [email-masked]
>>> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format)
>> to
>>> Proposed Standard
>>> 
>>> 
>>> The IESG has received a request from the Public-Key Infrastructure
>>> (X.509) WG (pkix) to consider the following document:
>>> 
>>> - 'Trust Anchor Format '
>>>    <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard
>>> 
>>> The IESG plans to make a decision in the next few weeks, and
> solicits
>>> final comments on this action.  Please send substantive comments to
>> the
>>> [email-masked] mailing lists by 2009-07-23. Exceptionally,
>>> comments may be sent to [email-masked] instead. In either case,
> please
>>> retain the beginning of the Subject line to allow automated sorting.
>>> 
>>> The file can be obtained via
>>> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt
>>> 
>>> 
>>> IESG discussion can be tracked via
>>> 
>> 
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag
>> =17
>>> 759&rfc_flag=0
>> Consider the environment before printing this mail.
>> "Thales e-Security Limited is incorporated in England and Wales with
>> company
>> registration number 2518805. Its registered office is located at 2
>> Dashwood
>> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
>> KT15
>> 2NX.
>> The information contained in this e-mail is confidential. It may also
>> be
>> privileged. It is only intended for the stated addressee(s) and access
>> to it
>> by any other person is unauthorised. If you are not an addressee or
> the
>> intended addressee, you must not disclose, copy, circulate or in any
>> other
>> way use or rely on the information contained in this e-mail. Such
>> unauthorised use may be unlawful. If you have received this e-mail in
>> error
>> please delete it (and all copies) from your system, please also inform
>> us
>> immediately on +44 (0)1844 201800 or email postmaster@thales-
>> esecurity.com.
>> Commercial matters detailed or referred to in this e-mail are subject
>> to a
>> written contract signed for and on behalf of Thales e-Security
>> Limited".
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf

Date: Tue, 14 Jul 2009 09:37:37 -0400
From: Sean Turner <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
Sender: [email-masked]

We need to align ECParameters with RFC 5480.  PKIX agreed to comment out 
  the specifiedCurve and namedCurve choices.  I leave the choice to you 
as to which way you'd like to fix it (though I tend to lean towards the 
1st):

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve})
  -- implicitCurve   NULL
  -- specifiedCurve  SpecifiedECDomain
  -- implicitCurve and specifiedCurve MUST NOT be used in PKIX.
  -- Details for specifiedCurve can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.
}

or

ECParameters ::= CHOICE {
  namedCurve      CURVE.&id({NamedCurve}),
  implicitCurve   NULL,
  specifiedCurve  SpecifiedECDomain
  -- specifiedCurve MUST NOT be used in PKIX.
  -- Details for SpecifiedECDomain can be found in [X9.62].
  -- Any future additions to this CHOICE should be coordinated
  -- with ANSI X.9.
}
WITH COMPONENTS {namedCurve PRESENT}

spt

Cc: "'Charles W. Gardiner'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
From: Kurt Zeilenga <[email-masked]>
To: Jim Schaad <[email-masked]>
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Sun, 12 Jul 2009 05:38:34 -0700
Sender: [email-masked]

On Jul 11, 2009, at 9:49 PM, Jim Schaad wrote:
>>
>> 4. PKIXExplicit88 has the statement "AttributeType ::=  
>> ATTRIBUTE.&id".
>> Why
>> not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor
>> point, but it seems to me that the present wording requires extra  
>> work
>> by a
>> computer or by a person trying to understand what is meant.  The
>> simpler
>> description is used in many other places, so why not this one?
>
> I might be willing to think about this type of change for the  
> benefit of a
> person, but not for the compiler. Taking your logic one step farther  
> it
> would make sense to eliminate the use of AttributeType and just use  
> OBJECT
> IDENTIFIER wherever AttributeType is used.  This would make it even  
> easier
> for the person reading the module.  This is one change that could be  
> made,
> however I don't know that I see a real benefit to making the change.

X.501(2008) uses:
   AttributeType  ::=  ATTRIBUTE.&id

Using
   AttributeType ::= OBJECT IDENTIFIER

in the PKIX module would, I think, would be confusing to readers of  
both specifications.  Consistency is a good thing.

Regarding other issues raised, I generally agree with Jim's response.   
In summary, I oppose making changes in response to Charlie's comment.

-- Kurt

From: "Jim Schaad" <[email-masked]>
To: "'Charles W. Gardiner'" <[email-masked]>, "'Stefan Santesson'" <[email-masked]>, <[email-masked]>
Subject: RE: WGLC on draft-ietf-pkix-new-asn1-05.txt
Date: Sun, 12 Jul 2009 07:49:00 +0300
Sender: [email-masked]

Please see the comments embedded in the message.

> [email-masked]] On Behalf Of Charles W. Gardiner
> Sent: Friday, July 10, 2009 6:57 PM
> To: Stefan Santesson; [email-masked]
> Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
> 
> 
>      My apologies for responding so late about this draft, but I have
> only
> recently had enough time to study carefully its implications for
> updating
> our ASN.1 "compiler" to accept the new notation.  So far I have several
> concerns:
> 
> 1. The files PKIXExplicit88 and PKIXImplicit88 import things from each
> other, creating an importing "loop".  This upsets the creation of ".h"
> files for C or C++ programs.  The looping can be prevented in the ".h"
> files with "#ifndef" statements, but the precedence of definitions will
> not
> always be correct.  This problem could be solved quite easily by taking
> some things out of either or both files and putting them in one or more
> other files which the PKIX*plicit88 files could import.

We have not introduced any new looping in the PKIX 5280 ASN.1 modules.
These modules have long had such loops in them.  If you go to a larger set
of modules to compile you will find even worse looping may occur.  Any ASN.1
compiler must be able to deal with this looping when doing emissions to .h
files.

> 
> 2. The ParamOptions described in AlgorithmInformation is not much use
> to a
> computer.  Translating the shades of necessity to numbers does not help
> either, particularly as the numbers are not in order of necessity.
> (What
> percentage of messages having parameters should be rejected if the
> preferredAbsent option is specified?)  Most of the options offered,
> namely
> required, absent and optional, can be achieved by choosing an
> appropriate
> form of the PARAM statement: for required, just give the TYPE; for
> absent,
> omit the PARAM statement completely; and for optional, use ARE OPTIONAL
> in
> the PARAM statement.  Perhaps inheritable could be dealt with by a
> variant
> of the ARE statement, or maybe that condition is implied by OPTION

We could order the values of ParamOptions if desired, however I do not
actually see any benefit to doing so.  No message should be rejected on
decoding when preferredAbsent is the value (the parameters should be decoded
and used), however when messages are encoded then the parameters should be
omitted.  The presence if this value in the object definition is to deal
with the text which says "the parameters for an algorithm have the type
NULL, the parameters SHOULD be omitted, but you MUST accept the parameters
if they are present."  This is, unfortunately a very common construction and
we need to represent this so that code can be written by the user (not the
compiler) that can correctly deal with it.  Having it emitted from the ASN.1
module rather than hand extracted from the text makes this more consistent.

> 
> 3. The disambiguation of SignatureAlgs and PublicKeys by the use of the
> file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant
> extension of the language.  Other cases use the name of a construct, as
> in
> the definition of SingleAttribute where it says ATTRIBUTE.&Type, but
> file
> names only appear in IMPORT statements.  Is this use of the language
> allowed in those difficult X68* documents? It might be simpler to
> change
> the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP
> (assuming that PKIXAlgs-2008 came first).  Or maybe both should be
> changed.

We looked at doing this both ways, that is using a single common name and
requiring the prefix of a module, and using distinguished names for each
module.  I finally decided that the use of a single common name makes it
clearer what the Object Set is used for and that clarity was worth requiring
that the module name (as defined in the import statement) be prefixed on the
single common name.

Please note that the reference to a variable as module.name was defined as
an acceptable part of the language in the 1988 ASN.1 syntax, while it was
not frequently used, it has always been in the language definition.

> 
> 4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".
> Why
> not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor
> point, but it seems to me that the present wording requires extra work
> by a
> computer or by a person trying to understand what is meant.  The
> simpler
> description is used in many other places, so why not this one?

I might be willing to think about this type of change for the benefit of a
person, but not for the compiler. Taking your logic one step farther it
would make sense to eliminate the use of AttributeType and just use OBJECT
IDENTIFIER wherever AttributeType is used.  This would make it even easier
for the person reading the module.  This is one change that could be made,
however I don't know that I see a real benefit to making the change.

> 
>      The draft document certainly takes advantage of the abstractions
> allowed by the 2002 notation, and in some ways makes things more
> comprehensible -- once one masters the lingo.  I think attention to the
> points noted above would make the document easier to use by machine.
> 
> Charlie Gardiner
> 

Jim Schaad

Date: Fri, 10 Jul 2009 11:57:11 -0400
To: Stefan Santesson <[email-masked]>, "[email-masked]" <[email-masked]>
From: "Charles W. Gardiner" <[email-masked]>
Subject: Re: WGLC on draft-ietf-pkix-new-asn1-05.txt
Sender: [email-masked]

     My apologies for responding so late about this draft, but I have only 
recently had enough time to study carefully its implications for updating 
our ASN.1 "compiler" to accept the new notation.  So far I have several 
concerns:

1. The files PKIXExplicit88 and PKIXImplicit88 import things from each 
other, creating an importing "loop".  This upsets the creation of ".h" 
files for C or C++ programs.  The looping can be prevented in the ".h" 
files with "#ifndef" statements, but the precedence of definitions will not 
always be correct.  This problem could be solved quite easily by taking 
some things out of either or both files and putting them in one or more 
other files which the PKIX*plicit88 files could import.

2. The ParamOptions described in AlgorithmInformation is not much use to a 
computer.  Translating the shades of necessity to numbers does not help 
either, particularly as the numbers are not in order of necessity.  (What 
percentage of messages having parameters should be rejected if the 
preferredAbsent option is specified?)  Most of the options offered, namely 
required, absent and optional, can be achieved by choosing an appropriate 
form of the PARAM statement: for required, just give the TYPE; for absent, 
omit the PARAM statement completely; and for optional, use ARE OPTIONAL in 
the PARAM statement.  Perhaps inheritable could be dealt with by a variant 
of the ARE statement, or maybe that condition is implied by OPTIONAL.

3. The disambiguation of SignatureAlgs and PublicKeys by the use of the 
file names, e.g PKIXAlgs-2008.SignatureAlgs, seems like a significant 
extension of the language.  Other cases use the name of a construct, as in 
the definition of SingleAttribute where it says ATTRIBUTE.&Type, but file 
names only appear in IMPORT statements.  Is this use of the language 
allowed in those difficult X68* documents? It might be simpler to change 
the names of the ambiguous terms in one case, e.g. SignatureAlgsOAEP 
(assuming that PKIXAlgs-2008 came first).  Or maybe both should be changed.

4. PKIXExplicit88 has the statement "AttributeType ::= ATTRIBUTE.&id".  Why 
not simply say AttributeType ::= OBJECT IDENTIFIER"?  This is a minor 
point, but it seems to me that the present wording requires extra work by a 
computer or by a person trying to understand what is meant.  The simpler 
description is used in many other places, so why not this one?

     The draft document certainly takes advantage of the abstractions 
allowed by the 2002 notation, and in some ways makes things more 
comprehensible -- once one masters the lingo.  I think attention to the 
points noted above would make the document easier to use by machine.

Charlie Gardiner

Reply-To: [email-masked]
From: "Denis Pinkas"<[email-masked]>
To: "ietf-pkix"<[email-masked]>
CC: "Stefan Santesson"<[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Date: Fri, 10 Jul 2009 15:55:38 +0200
Sender: [email-masked]

------=_NextPart_09071015553780877458541_002
Content-Type: text/plain; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

No doubt that everybody agrees that RFC 3161 should be updated to allow t=
he use of RFC 5035 [ESSV2].=20
The question is whether other changes should also be made.

The major differences from RFC 3161 [RFC3161] are summarized on page 3 of=
 the draft and are listed below:

     1 - the document has been aligned with RFC 3628 to make the=20
         difference between a time-stamping unit (TSU) and a TSA.

     2 - the document makes the difference between a time-stamping=20
         service and a time-stamping unit and allows a time-stamping=20
         service to support more than one time-stamping unit.

     3 - the format of the subject field of a TSU certificate is now=20
         defined.

and also some minor updates :

     4 - informative references to ISO 18014-1 [ISO18014-1],=20
         ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been=20
         added.

     5 - a new normative ASN1 module to refer to the ASN.1 modules=20
         from the latest RFCs.=20

At the moment, RFC 3161 makes confusion between three different concepts:=
=20
a TSA, a TSS and a TSU, respectively a Time-Stamping Authority,=20
a Time-Stamping Service and a Time-Stamping Unit.=20

IMO, the document should be cleaned to call a spade a spade.

Historically, the notions applicable to TSAs have been copied and pasted=20
from the documents related to CAs. Since a CA had one private key, a TSA=20
had one private key as well, but this was short looking.

The CA advertises one public key, or more exactly one trust anchor, usual=
ly=20
by issuing a self-signed certificate. This private key, when in use,=20
is supported by one HSH (Hardware Security Module). This private key need=
s=20
to be saved in order to be restored in case of a problem. The time for re=
storation=20
is usually not critical (this may take a few minutes or even a few hours)=
.=20
The life time of a CA certificate (or CA public key) is usually between o=
ne and=20
15 years and should not be changed earlier, unless strictly needed.

In order to provide time-stamp tokens (TSTs) with high availability, more=
 than=20
one TSU is usually needed. These units altogether provide a TSS (Time-Sta=
mping Service)=20
that is managed by an Authority called a TSA (Time-Stamping Authority).

The key used to sign TSTs is not the key from a TSA, but the key from a T=
SU.

In order to a high level of security, the key used to sign to TSTs should=
 NOT be saved=20
and restored. It should be generated by the TSU itself and should NOT be =
exported=20
outside the TSU. If the key of the TSU is erased purposely or by accident=
, a new key pair=20
and certificate should be generated. Since TSU certificates are provided =
by a CA,=20
TST verification systems do not need to change any trust anchor. Some TSU=
s may even=20
use short-lived TSU certificates, e.g. a TSU certificate valid for one we=
ek or even one day.=20
However, it is necessary to be able to know the name of the TSA when look=
ing at the=20
subject DN from the TSU certificate.

Along these lines, several changes should be made to RFC 3161. To mention=
 a few of them:

RFC 3161:
   If the TSA does not recognize the hash=20
   algorithm or knows that the hash algorithm is weak (a decision left=20
   to the discretion of each individual TSA), then the TSA SHOULD refuse=20
   to provide the time-stamp token by returning a pkiStatusInfo of=20
   'bad_alg'.

Proposed change :
   If the TSS does not recognize the hash=20
   algorithm or knows that the hash algorithm is weak (a decision left=20
    to the discretion of each individual TSA), then the TSS SHOULD refuse=
=20
    to provide the time-stamp token by returning a pkiStatusInfo of=20
    'bad_alg'.

RFC3161:
   The certificate identifier (ESSCertID) of the=20
   TSA certificate MUST be included as a signerInfo attribute inside a=20
  SigningCertificate attribute.

Proposed change:
   The certificate identifier (either ESSCertID  or ESSCertIDv2) of the T=
SU certificate=20
  MUST be included as a signerInfo attribute inside a SigningCertificate =
attribute.

RFC 3161:
   The serialNumber field is an integer assigned by the TSA to each=20
  TimeStampToken.

Proposed change:=20
   The serialNumber field is an integer assigned by the TSU to each=20
   TimeStampToken.

RFC 3161:
   genTime is the time at which the time-stamp token has been created by=20
=20
   the TSA.

Proposed change:
   genTime is the time at which the time-stamp token has been created by=20
   the TSU.

RF3161:
   The purpose of the tsa field is to give a hint in identifying the=20
   name of the TSA.

Proposed change:
   The purpose of the tsu field is to give a hint in identifying the=20
   name of the TSU.

Note that the difference between a TSU and a TSA that is already present=20
in RFC 3628 (Informational) is also present in ISO 18014 and in ETSI TS 1=
02 023.
All these documents have been issued after RFC 3161.

Even, if the bits on the wire are the same, the meaning of these bits=20
would not necessarily be the same. For example, the ESSCertID refers to=20
a  certificate from a TSU, not from a TSA.

Since the changes to be done are scattered around the document, a new dra=
ft=20
would seem more appropriate, hence why a new draft has been proposed.

>From another angle, should we have an update to RFC 3161 or a new draft?=20
An update would have to advantage to keep the magic number 3161 that ever=
ybody=20
identifies with TSP.

In any case, I believe that both the ESSCertIDv2 and the terminology aspe=
cts=20
should be addressed to align RFC 3161 with the documents issued after it.=
=20

Denis
----- Message re=E7u -----=20
De : Stefan Santesson=20
=C0 : Pope,Nick,ietf-pkix=20
Date : 2009-07-09, 13:13:15
Sujet : Re: Way forward - updating RFC 3161

I conclude that the list so far is unanimous in its view of not accepting=
 the approach of draft-ietf-pkix-rfc3161bis-01.
Even though we have not heard the opinion of the draft author, It feels t=
hat we will have a strong consensus for just making a short update docume=
nt.

/Stefan

On 09-07-01 12:47 PM, "Pope, Nick" <[email-masked]> wrote=
:

Stefan,
=20
I also agree with the approach of updating RFC 3161.  Changing the model =
of RFC 3161 is only going to cause confusion.
=20
The implementation architecture concepts used in the earlier proposal are=
 already described in RFC 3628  and so I see no need for further steps on=
 that aspect.
=20
Nick
=20

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]]=20
Sent: 01 July 2009 02:00
To: [email-masked]
Cc: Denis Pinkas; Pope, Nick
Subject: Way forward - updating RFC 3161

We need to resolve how to update RFC 3161 with respect to allowing suppor=
t of RFC 5035 (ESSV2)
One particular reason is because ETSI ESI is dependent on progression of =
this issue in PKIX.

I would like to open this issue up for debate and then hopefully conclude=
 this issue, possibly after a straw poll.

My personal opinion, and what I interpret as the general opinion of this =
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as b=
asis for updating rfc 3161. This draft intends to obsolete RFC 3161 and i=
ntroduces major changes to terminology and role description to align RFC =
3161 with the informational document RFC 3628.

It is problematic to introduce such major changes to a standard that is w=
idely deployed. It is neither required from a protocol implementation per=
spective as these changes are not intended to change any bits on the wire=
. The optional usage of ESSV2 does not motivate a total rewrite of the cu=
rrent standard, but is better handled in an update RFC.

If description of roles and responsibilities that so not change any bits =
on the wire need to be clarified in relation to RFC 3628 and RFC 3161, th=
en this should be handled either as an update to RFC 3628 or as a separat=
e informational document.

/Stefan=20

------=_NextPart_09071015553780877458541_002
Content-Type: text/html; 
	charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML><HEAD><TITLE></TITLE>
<META content=3D"KsDHTMLEDLib.ocx, FreeWare HTML Editor 1.164.2, =A9 Kurt=
 Senfer"=20
name=3DGENERATOR>
<META http-equiv=3DContent-Type content=3D"text/html; charset=3Diso-8859-=
1"></HEAD>
<BODY style=3D"FONT-SIZE: 10pt; FONT-FAMILY: Tahoma" leftMargin=3D5 topMa=
rgin=3D5=20
#ffffff>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"></SPAN>&nbsp;</DIV>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA">No=20
doubt that everybody agrees that RFC 3161 should be updated to allow the =
use of=20
RFC 5035 [ESSV2]. <BR>The question is whether other changes should also b=
e=20
made.<BR><BR>The major differences from RFC 3161 [RFC3161] are summarized=
 on=20
page 3 of the draft and are listed below:<BR><BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp; </SPAN>1 - the docum=
ent has=20
been aligned with RFC 3628 to make the <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>difference between a time-stamping unit (TSU) and a TSA.<BR><BR><S=
PAN=20
style=3D"mso-spacerun: yes">&nbsp;</SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp; </SPAN>2 - the document ma=
kes the=20
difference between a time-stamping <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>service and a time-stamping unit and allows a time-stamping <BR><S=
PAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>service to support more than one time-stamping unit.<BR><BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;</SPAN>3 - the format of th=
e subject=20
field of a TSU certificate is now <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>defined.<BR><BR>and also some minor updates :<BR><BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>4 - informative references=
 to ISO=20
18014-1 [ISO18014-1], <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>ISO 18014-2 [ISO18014-2] and ISO 18014-3 [ISO18014-3] have been <B=
R><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>added.<BR><BR><SPAN style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;=
=20
</SPAN><SPAN style=3D"mso-spacerun: yes">&nbsp;</SPAN>5 - a new normative=
 ASN1=20
module to refer to the ASN.1 modules <BR><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nb=
sp;=20
</SPAN>from the latest RFCs. <BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>At the moment, RFC 3161 makes confusion=
 between=20
three different concepts: <BR>a TSA, a TSS and a TSU, respectively a=20
Time-Stamping Authority, <BR>a Time-Stamping Service and a Time-Stamping =
Unit.=20
</FONT></SPAN></DIV>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3></FONT></SPAN>&nbsp;</DIV>
<DIV><FONT face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA">IMO,=20
the document should be cleaned to call a spade a spade.<BR><BR>Historical=
ly, the=20
notions applicable to TSAs have been copied and pasted <BR>from the docum=
ents=20
related to CAs. Since a CA had one private key, a TSA <BR>had one private=
 key as=20
well, but this was short looking.<BR><BR>The CA advertises one public key=
, or=20
more exactly one trust anchor, usually <BR>by issuing a self-signed certi=
ficate.=20
This private key, when in use, <BR>is supported by one HSH (Hardware Secu=
rity=20
Module). This private key needs <BR>to be saved in order to be restored i=
n case=20
of a problem. The time for restoration <BR>is usually not critical (this =
may=20
take a few minutes or even a few hours). <BR>The life time of a CA certif=
icate=20
(or CA public key) is usually between&nbsp;one and <BR>15 years and shoul=
d not=20
be changed earlier, unless strictly needed.<BR><BR>In order to provide=20
time-stamp tokens (TSTs) with high availability, more than <BR>one TSU is=
=20
usually needed. These units altogether provide a TSS (Time-Stamping Servi=
ce)=20
<BR>that is managed by an Authority called a TSA (Time-Stamping=20
Authority).<BR><BR>The key used to sign TSTs is not the key from a TSA, b=
ut the=20
key from a TSU.<BR><BR>In order to a high level of security, the key used=
 to=20
sign to TSTs should NOT be saved <BR>and restored. It should be generated=
 by the=20
TSU itself and should NOT be exported <BR>outside the TSU. If the key of =
the TSU=20
is erased purposely or by accident, a new key pair <BR>and certificate sh=
ould be=20
generated. Since TSU certificates are provided by a CA, <BR>TST verificat=
ion=20
systems do not need to change any trust anchor. Some TSUs may even <BR>us=
e=20
short-lived TSU certificates, e.g. a TSU certificate valid for one week o=
r even=20
one day. <BR>However, it is necessary to be able to know the name of the =
TSA=20
when looking at the <BR>subject DN from the TSU certificate.<BR><BR>Along=
 these=20
lines, several changes should be made to RFC 3161. To mention a few of=20
them:<BR><BR>RFC 3161:<BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>If the TSA does not recog=
nize the=20
hash</SPAN> </FONT></FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><?xml:namespace prefix =3D o ns =3D=20
"urn:schemas-microsoft-com:office:office" /><o:p><FONT face=3D"Times New =
Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>algorithm or knows that t=
he hash=20
algorithm is weak (a decision left</SPAN><FONT face=3D"Times New Roman" s=
ize=3D3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to the discretion of each=
=20
individual TSA), then the TSA SHOULD refuse</SPAN><FONT face=3D"Times New=
 Roman"=20
size=3D3> </FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to provide the time-stamp=
 token by=20
returning a pkiStatusInfo of</SPAN><FONT face=3D"Times New Roman" size=3D=
3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>'bad_alg'.<BR></SPAN><SPA=
N=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Proposed change&nbsp;:<BR></FONT></SPAN=
><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>If the TSS does not recog=
nize the=20
hash</SPAN><FONT face=3D"Times New Roman" size=3D3> </FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>algorithm or knows that t=
he hash=20
algorithm is weak (a decision left</SPAN><FONT face=3D"Times New Roman" s=
ize=3D3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to the discretion of each=
=20
individual TSA), then the TSS SHOULD refuse</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>to provide the time-stamp=
 token by=20
returning a pkiStatusInfo of</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>'bad_alg'.<BR></SPAN><SPA=
N=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>RFC3161:<BR></FONT></SPAN><SPAN lang=3D=
EN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The certificate identifie=
r=20
(ESSCertID) of the</SPAN><FONT face=3D"Times New Roman" size=3D3> </FONT>=
</P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p>&nbsp;</o:p></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp;</SPAN>TSA certificate MUST be in=
cluded as=20
a signerInfo attribute inside a</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN style=3D"mso-spacerun: yes"=
>=20
</SPAN>SigningCertificate attribute.<BR><BR>Proposed=20
change:<BR></FONT></FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The certificate identifie=
r (either=20
ESSCertID&nbsp;<SPAN style=3D"mso-spacerun: yes"> </SPAN>or ESSCertIDv2) =
of the=20
TSU certificate <BR>&nbsp; MUST be included as a&nbsp;</SPAN><FONT=20
face=3D"Times New Roman"><FONT size=3D3><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA">signerInfo=20
attribute inside a SigningCertificate attribute.<BR><BR>RFC=20
3161:<BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The serialNumber field is=
 an=20
integer assigned by the TSA to each</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><FONT face=3D"Times New Roman"><FONT s=
ize=3D3><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes"> </SPAN>TimeStampToken.<BR><BR>Proposed chang=
e:=20
<BR></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The serialNumber field is=
 an=20
integer assigned by the TSU to each</SPAN> </FONT></FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>TimeStampToken.<BR></SPAN><SPAN=
=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>RFC 3161:<BR></FONT></SPAN><SPAN lang=3D=
EN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>genTime is the time at wh=
ich the=20
time-stamp token has been created by</SPAN><FONT face=3D"Times New Roman"=
 size=3D3>=20
</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>the TSA.<BR></SPAN><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Proposed change:<BR></FONT></SPAN><SPAN=
 lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>genTime is the time at wh=
ich the=20
time-stamp token has been created by</SPAN><FONT face=3D"Times New Roman"=
 size=3D3>=20
</FONT></DIV>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>the TSU.<BR></SPAN><SPAN lang=3D=
EN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>RF3161:<BR></FONT></SPAN><SPAN lang=3DE=
N-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The purpose of the tsa fi=
eld is to=20
give a hint in identifying the</SPAN><FONT face=3D"Times New Roman" size=3D=
3>=20
</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3>&nbsp;</FONT></o:p></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp; </SPAN>name of the TSA.<BR></SPAN><SPA=
N=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Proposed change:<BR></FONT></SPAN><SPAN=
 lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>The purpose of the tsu fi=
eld is to=20
give a hint in identifying the</SPAN><FONT face=3D"Times New Roman" size=3D=
3>=20
</FONT></P>
<P class=3DMsoNormal style=3D"MARGIN: 0cm 0cm 0pt"><SPAN lang=3DEN-US=20
style=3D"mso-ansi-language: EN-US"><o:p><FONT face=3D"Times New Roman"=20
size=3D3></FONT></o:p></SPAN></P>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 12pt; FONT-FAMILY: 'Times New Roman'; mso-fareast-fon=
t-family: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-langua=
ge: FR; mso-bidi-language: AR-SA"><SPAN=20
style=3D"mso-spacerun: yes">&nbsp;&nbsp; </SPAN>name of the TSU.<BR></SPA=
N><SPAN=20
lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Note that the difference between a TSU =
and a TSA=20
that is already present <BR>in RFC 3628 (Informational) is also present i=
n ISO=20
18014 and in ETSI </FONT></SPAN><SPAN=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: FR; mso-fareast-language: FR;=
 mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>TS 102 023</FONT></SPAN><SPAN lang=3DEN=
-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>.</FONT></SPAN></DIV>
<DIV><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><FONT=20
face=3D"Times New Roman" size=3D3>All these documents have been issued af=
ter RFC=20
3161.<BR><BR>Even, if the bits on the wire are the same, the meaning of t=
hese=20
bits <BR>would not necessarily be the same. For example, the ESSCertID re=
fers=20
to&nbsp;<BR>a &nbsp;certificate from a TSU, not from a TSA.<BR><BR>Since =
the=20
changes to be done are scattered around the document, a new draft <BR>wou=
ld seem=20
more appropriate, hence why a new draft has been proposed.<BR><BR>From an=
other=20
angle, should we have an update to RFC 3161 or a new draft? <BR>An update=
 would=20
have to advantage to keep the magic number 3161 that everybody <BR>identi=
fies=20
with TSP.<BR><BR>In any case, I believe that both the ESSCertIDv2 and the=
=20
terminology aspects <BR>should be addressed to align RFC 3161 with the do=
cuments=20
issued after it. <BR></FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"><BR><FONT=20
face=3D"Times New Roman" size=3D3>Denis</FONT></SPAN><SPAN lang=3DEN-US=20
style=3D"FONT-SIZE: 10pt; FONT-FAMILY: 'Courier New'; mso-fareast-font-fa=
mily: 'Times New Roman'; mso-ansi-language: EN-US; mso-fareast-language: =
FR; mso-bidi-language: AR-SA"></DIV></SPAN>
<BLOCKQUOTE=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-=
LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal">-----=20
  Message re=E7u ----- </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; BACKGROUND: #e4e4e4; LINE=
-HEIGHT: normal; FONT-STYLE: normal; FONT-VARIANT: normal; font-color: bl=
ack"><B>De=20
  :</B> <A href=3D"mailto :[email-masked]">Stefan Santesson</A> </DIV=
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>=C0=20
  :</B> <A=20
  href=3D"mailto :[email-masked],[email-masked]">Pope,=
Nick,ietf-pkix</A>=20
  </DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Date=20
  :</B> 2009-07-09, 13:13:15</DIV>
  <DIV=20
  style=3D"FONT-WEIGHT: normal; FONT-SIZE: 9pt; LINE-HEIGHT: normal; FONT=
-STYLE: normal; FONT-VARIANT: normal"><B>Sujet=20
  :</B> Re: Way forward - updating RFC 3161</DIV>
  <DIV><BR></DIV>
  <DIV></DIV>
  <DIV></DIV>
  <DIV><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
  style=3D"FONT-SIZE: 11pt">I conclude that the list so far is unanimous =
in its=20
  view of not accepting the approach of draft-ietf-pkix-rfc3161bis-01.<BR=
>Even=20
  though we have not heard the opinion of the draft author, It feels that=
 we=20
  will have a strong consensus for just making a short update=20
  document.<BR><BR>/Stefan<BR><BR><BR>On 09-07-01 12:47 PM, "Pope, Nick" =
&lt;<A=20
  href=3D"[email-masked]">[email-masked]<=
/A>&gt;=20
  wrote:<BR><BR></SPAN></FONT>
  <BLOCKQUOTE><FONT color=3D#000080><FONT size=3D2><FONT face=3DArial><SP=
AN=20
    style=3D"FONT-SIZE: 10pt">Stefan,<BR>&nbsp;<BR>I also agree with the =
approach=20
    of updating RFC 3161. &nbsp;Changing the model of RFC 3161 is only go=
ing to=20
    cause confusion.<BR>&nbsp;<BR>The implementation architecture concept=
s used=20
    in the earlier proposal are already described in RFC 3628 &nbsp;and s=
o I see=20
    no need for further steps on that=20
    aspect.<BR>&nbsp;<BR>Nick<BR>&nbsp;<BR></SPAN></FONT></FONT></FONT><F=
ONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 11pt"><BR></SPAN></FONT><FONT size=3D2><FONT=20
    face=3D"Tahoma, Verdana, Helvetica, Arial"><SPAN=20
    style=3D"FONT-SIZE: 10pt">-----Original Message-----<BR><B>From:</B> =
Stefan=20
    Santesson [<A=20
    href=3D"mailto:[email-masked]">mailto:[email-masked]</A>]=20
    <BR><B>Sent:</B> 01 July 2009 02:00<BR><B>To:</B> <A=20
    href=3D"[email-masked]">[email-masked]</A><BR><B>Cc:</B> Denis =
Pinkas;=20
    Pope, Nick<BR><B>Subject:</B> Way forward - updating RFC=20
    3161<BR></SPAN></FONT></FONT><FONT face=3D"Times New Roman"><SPAN=20
    style=3D"FONT-SIZE: 12pt"><BR></SPAN></FONT><FONT=20
    face=3D"Calibri, Verdana, Helvetica, Arial"><SPAN style=3D"FONT-SIZE:=
 11pt">We=20
    need to resolve how to update RFC 3161 with respect to allowing suppo=
rt of=20
    RFC 5035 (ESSV2)<BR>One particular reason is because ETSI ESI is depe=
ndent=20
    on progression of this issue in PKIX.<BR><BR>I would like to open thi=
s issue=20
    up for debate and then hopefully conclude this issue, possibly after =
a straw=20
    poll.<BR><BR>My personal opinion, and what I interpret as the general=
=20
    opinion of this working group is that we should reject=20
    draft-ietf-pkix-rfc3161bis-01 as basis for updating rfc 3161. This dr=
aft=20
    intends to obsolete RFC 3161 and introduces major changes to terminol=
ogy and=20
    role description to align RFC 3161 with the informational document RF=
C=20
    3628.<BR><BR>It is problematic to introduce such major changes to a s=
tandard=20
    that is widely deployed. It is neither required from a protocol=20
    implementation perspective as these changes are not intended to chang=
e any=20
    bits on the wire. The optional usage of ESSV2 does not motivate a tot=
al=20
    rewrite of the current standard, but is better handled in an update=20
    RFC.<BR><BR>If description of roles and responsibilities that so not =
change=20
    any bits on the wire need to be clarified in relation to RFC 3628 and=
 RFC=20
    3161, then this should be handled either as an update to RFC 3628 or =
as a=20
    separate informational document.<BR><BR>/Stefan</SPAN></FONT><FONT=20
    face=3D"Times New Roman"><SPAN style=3D"FONT-SIZE: 12pt">=20
    <BR></SPAN></FONT><FONT face=3D"Calibri, Verdana, Helvetica, Arial"><=
SPAN=20
    style=3D"FONT-SIZE: 11pt"><BR></SPAN></FONT></BLOCKQUOTE></DIV></BLOC=
KQUOTE></BODY></HTML>

------=_NextPart_09071015553780877458541_002--

Content-class: urn:content-classes:message
Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Fri, 10 Jul 2009 07:50:56 -0400
From: "Carl Wallace" <[email-masked]>
To: "Pope, Nick" <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This document has been discussed previously relative to TAF.  A portion
of that discussion is here:
http://www.imc.org/ietf-pkix/mail-archive/msg05573.html.=20

> [email-masked]] On Behalf Of Pope, Nick
> Sent: Friday, July 10, 2009 4:02 AM
> To: [email-masked]'; [email-masked]
> Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor
Format)
> to Proposed Standard
>=20
>=20
> Perhaps the authors should be aware of the existing European Technical
> Specification for trust status lists (TS 102 231), which have some
> overlap
> in function with the Trust anchor list in this internet draft.
>=20
> This is being adopted by all EU member states as a means of publishing
> information on CA recognised as trustworthy under the national
> accreditation
> or supervisory schemes.
>=20
> To obtain a copy go to:
>=20
> http://pda.etsi.org/pda/queryform.asp
>=20
> and enter TS 102 231 in the search box.
>=20
> Nick Pope
> Thales e-Security Ltd
>=20
>=20
>=20
> [email-masked]]
> > On Behalf Of The IESG
> > Sent: 10 July 2009 01:14
> > To: IETF-Announce
> > Cc: [email-masked]
> > Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format)
> to
> > Proposed Standard
> >
> >
> > The IESG has received a request from the Public-Key Infrastructure
> > (X.509) WG (pkix) to consider the following document:
> >
> > - 'Trust Anchor Format '
> >    <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard
> >
> > The IESG plans to make a decision in the next few weeks, and
solicits
> > final comments on this action.  Please send substantive comments to
> the
> > [email-masked] mailing lists by 2009-07-23. Exceptionally,
> > comments may be sent to [email-masked] instead. In either case,
please
> > retain the beginning of the Subject line to allow automated sorting.
> >
> > The file can be obtained via
> > http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt
> >
> >
> > IESG discussion can be tracked via
> >
>
https://datatracker.ietf.org/public/pidtracker.cgi?command=3Dview_id&dTag=

> =3D17
> > 759&rfc_flag=3D0
> Consider the environment before printing this mail.
> "Thales e-Security Limited is incorporated in England and Wales with
> company
> registration number 2518805. Its registered office is located at 2
> Dashwood
> Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey
> KT15
> 2NX.
> The information contained in this e-mail is confidential. It may also
> be
> privileged. It is only intended for the stated addressee(s) and access
> to it
> by any other person is unauthorised. If you are not an addressee or
the
> intended addressee, you must not disclose, copy, circulate or in any
> other
> way use or rely on the information contained in this e-mail. Such
> unauthorised use may be unlawful. If you have received this e-mail in
> error
> please delete it (and all copies) from your system, please also inform
> us
> immediately on +44 (0)1844 201800 or email postmaster@thales-
> esecurity.com.
> Commercial matters detailed or referred to in this e-mail are subject
> to a
> written contract signed for and on behalf of Thales e-Security
> Limited".

From: "Pope, Nick" <[email-masked]>
To: "[email-masked]'" <[email-masked]>, [email-masked]
Subject: RE: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Fri, 10 Jul 2009 09:02:01 +0100
Sender: [email-masked]

Perhaps the authors should be aware of the existing European Technical
Specification for trust status lists (TS 102 231), which have some overlap
in function with the Trust anchor list in this internet draft.

This is being adopted by all EU member states as a means of publishing
information on CA recognised as trustworthy under the national accreditation
or supervisory schemes.

To obtain a copy go to:

http://pda.etsi.org/pda/queryform.asp

and enter TS 102 231 in the search box.

Nick Pope
Thales e-Security Ltd

> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of The IESG
> Sent: 10 July 2009 01:14
> To: IETF-Announce
> Cc: [email-masked]
> Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
> Proposed Standard
> 
> 
> The IESG has received a request from the Public-Key Infrastructure
> (X.509) WG (pkix) to consider the following document:
> 
> - 'Trust Anchor Format '
>    <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard
> 
> The IESG plans to make a decision in the next few weeks, and solicits
> final comments on this action.  Please send substantive comments to the
> [email-masked] mailing lists by 2009-07-23. Exceptionally,
> comments may be sent to [email-masked] instead. In either case, please
> retain the beginning of the Subject line to allow automated sorting.
> 
> The file can be obtained via
> http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt
> 
> 
> IESG discussion can be tracked via
> https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17
> 759&rfc_flag=0
Consider the environment before printing this mail.
"Thales e-Security Limited is incorporated in England and Wales with company
registration number 2518805. Its registered office is located at 2 Dashwood
Lang Road, The Bourne Business Park, Addlestone, Nr. Weybridge, Surrey KT15
2NX.
The information contained in this e-mail is confidential. It may also be
privileged. It is only intended for the stated addressee(s) and access to it
by any other person is unauthorised. If you are not an addressee or the
intended addressee, you must not disclose, copy, circulate or in any other
way use or rely on the information contained in this e-mail. Such
unauthorised use may be unlawful. If you have received this e-mail in error
please delete it (and all copies) from your system, please also inform us
immediately on +44 (0)1844 201800 or email [email-masked].
Commercial matters detailed or referred to in this e-mail are subject to a
written contract signed for and on behalf of Thales e-Security Limited". 

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Reply-to: [email-masked]
CC: <[email-masked]>
Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to Proposed Standard
Date: Thu,  9 Jul 2009 17:13:41 -0700 (PDT)
Sender: [email-masked]

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

- 'Trust Anchor Format '
   <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-07-23. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17759&rfc_flag=0

To: IETF-Announce <[email-masked]>
From: The IESG <[email-masked]>
Reply-to: [email-masked]
CC: <[email-masked]>
Subject: Last Call: draft-ietf-pkix-ta-format (Trust Anchor Format) to
Date: Thu,  9 Jul 2009 14:31:42 -0700 (PDT)
Sender: [email-masked]

Proposed Standard

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

- 'Trust Anchor Format '
   <draft-ietf-pkix-ta-format-03.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send substantive comments to the
[email-masked] mailing lists by 2009-07-23. Exceptionally, 
comments may be sent to [email-masked] instead. In either case, please 
retain the beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-pkix-ta-format-03.txt

IESG discussion can be tracked via
https://datatracker.ietf.org/public/pidtracker.cgi?command=view_id&dTag=17759&rfc_flag=0

Date: Thu, 09 Jul 2009 13:13:15 +0200
Subject: Re: Way forward - updating RFC 3161
From: Stefan Santesson <[email-masked]>
To: "Pope, Nick" <[email-masked]>, <[email-masked]>
CC: Denis Pinkas <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3329989996_27827715
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

I conclude that the list so far is unanimous in its view of not accepting
the approach of draft-ietf-pkix-rfc3161bis-01.
Even though we have not heard the opinion of the draft author, It feels that
we will have a strong consensus for just making a short update document.

/Stefan

On 09-07-01 12:47 PM, "Pope, Nick" <[email-masked]> wrote:

> Stefan,
>  
> I also agree with the approach of updating RFC 3161.  Changing the model of
> RFC 3161 is only going to cause confusion.
>  
> The implementation architecture concepts used in the earlier proposal are
> already described in RFC 3628  and so I see no need for further steps on that
> aspect.
>  
> Nick
>  
> 
> Sent: 01 July 2009 02:00
> To: [email-masked]
> Cc: Denis Pinkas; Pope, Nick
> Subject: Way forward - updating RFC 3161
>  
> We need to resolve how to update RFC 3161 with respect to allowing support of
> RFC 5035 (ESSV2)
> One particular reason is because ETSI ESI is dependent on progression of this
> issue in PKIX.
> 
> I would like to open this issue up for debate and then hopefully conclude this
> issue, possibly after a straw poll.
> 
> My personal opinion, and what I interpret as the general opinion of this
> working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis
> for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduces
> major changes to terminology and role description to align RFC 3161 with the
> informational document RFC 3628.
> 
> It is problematic to introduce such major changes to a standard that is widely
> deployed. It is neither required from a protocol implementation perspective as
> these changes are not intended to change any bits on the wire. The optional
> usage of ESSV2 does not motivate a total rewrite of the current standard, but
> is better handled in an update RFC.
> 
> If description of roles and responsibilities that so not change any bits on
> the wire need to be clarified in relation to RFC 3628 and RFC 3161, then this
> should be handled either as an update to RFC 3628 or as a separate
> informational document.
> 
> /Stefan 
> 

--B_3329989996_27827715
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: Way forward - updating RFC 3161</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'>I conclude that the list so far is unanimous in its view of not accepting =
the approach of draft-ietf-pkix-rfc3161bis-01.<BR>
Even though we have not heard the opinion of the draft author, It feels tha=
t we will have a strong consensus for just making a short update document.<B=
R>
<BR>
/Stefan<BR>
<BR>
<BR>
On 09-07-01 12:47 PM, &quot;Pope, Nick&quot; &lt;<a href=3D"Nick.Pope@thales-=
esecurity.com">[email-masked]</a>&gt; wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT COLOR=3D"#000080"><FONT SIZE=3D"2"><FONT FACE=3D"=
Arial"><SPAN STYLE=3D'font-size:10pt'>Stefan,<BR>
&nbsp;<BR>
I also agree with the approach of updating RFC 3161. &nbsp;Changing the mod=
el of RFC 3161 is only going to cause confusion.<BR>
&nbsp;<BR>
The implementation architecture concepts used in the earlier proposal are a=
lready described in RFC 3628 &nbsp;and so I see no need for further steps on=
 that aspect.<BR>
&nbsp;<BR>
Nick<BR>
&nbsp;<BR>
</SPAN></FONT></FONT></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:11pt'><BR>
</SPAN></FONT><FONT SIZE=3D"2"><FONT FACE=3D"Tahoma, Verdana, Helvetica, Arial"=
><SPAN STYLE=3D'font-size:10pt'>-----Original Message-----<BR>
<B>From:</B> Stefan Santesson [<a href=3D"mailto:[email-masked]">mailto:s=
[email-masked]</a>] <BR>
<B>Sent:</B> 01 July 2009 02:00<BR>
<B>To:</B> <a href=3D"[email-masked]">[email-masked]</a><BR>
<B>Cc:</B> Denis Pinkas; Pope, Nick<BR>
<B>Subject:</B> Way forward - updating RFC 3161<BR>
</SPAN></FONT></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'>We need to resolve how to update RFC 3161 with respect to al=
lowing support of RFC 5035 (ESSV2)<BR>
One particular reason is because ETSI ESI is dependent on progression of th=
is issue in PKIX.<BR>
<BR>
I would like to open this issue up for debate and then hopefully conclude t=
his issue, possibly after a straw poll.<BR>
<BR>
My personal opinion, and what I interpret as the general opinion of this wo=
rking group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis =
for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduce=
s major changes to terminology and role description to align RFC 3161 with t=
he informational document RFC 3628.<BR>
<BR>
It is problematic to introduce such major changes to a standard that is wid=
ely deployed. It is neither required from a protocol implementation perspect=
ive as these changes are not intended to change any bits on the wire. The op=
tional usage of ESSV2 does not motivate a total rewrite of the current stand=
ard, but is better handled in an update RFC.<BR>
<BR>
If description of roles and responsibilities that so not change any bits on=
 the wire need to be clarified in relation to RFC 3628 and RFC 3161, then th=
is should be handled either as an update to RFC 3628 or as a separate inform=
ational document.<BR>
<BR>
/Stefan</SPAN></FONT><FONT FACE=3D"Times New Roman"><SPAN STYLE=3D'font-size:12=
pt'> <BR>
</SPAN></FONT><FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'=
font-size:11pt'><BR>
</SPAN></FONT></BLOCKQUOTE>
</BODY>
</HTML>

--B_3329989996_27827715--

Date: Thu, 09 Jul 2009 03:06:41 +0200
Subject: WGLC on draft-ietf-pkix-new-asn1-05.txt
From: Stefan Santesson <[email-masked]>
To: "[email-masked]" <[email-masked]>
Sender: [email-masked]

> This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

--B_3329953602_25631355
Content-type: text/plain;
	charset="US-ASCII"
Content-transfer-encoding: 7bit

Initiating WG last call on draft-ietf-pkix-new-asn1-05.txt
Last call ends on Friday July 24.

/Stefan

--B_3329953602_25631355
Content-type: text/html;
	charset="US-ASCII"
Content-transfer-encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>WGLC on draft-ietf-pkix-new-asn1-05.txt</TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:11pt=
'><BR>
Initiating WG last call on </SPAN></FONT><FONT SIZE=3D"1"><FONT FACE=3D"Geneva,=
 Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:12px'>draft-ietf-pkix-new=
-asn1-05.txt<BR>
Last call ends on Friday July 24.<BR>
<BR>
/Stefan</SPAN></FONT></FONT>
</BODY>
</HTML>

--B_3329953602_25631355--

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: Document Action: 'Traceable Anonymous Certificate' to Experimental RFC
Date: Mon,  6 Jul 2009 10:45:48 -0700 (PDT)
Sender: [email-masked]

The IESG has approved the following document:

- 'Traceable Anonymous Certificate '
   <draft-ietf-pkix-tac-04.txt> as an Experimental RFC

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

The IESG contact persons are Tim Polk and Pasi Eronen.

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

Technical Summary

   This document describes a model for issuing X.509 certificates in
which the certificates do not contain the "true" name of the user, and
thus provide some level of anonymity. Traceable Anonymous Certificates
(TACs) are issued by a CA that is divided into two parts. One part
verifies and records the identity of the user to whom the certificate is
issued, and the other issues the certificate to the user but does not know
the user's identity.  The certificates issued under the TAC model are
intended primary for use in web access (and not in applications such as
e-mail). The model allows an aggrieved party to request that a TAC CA
divulge the identity of a user who has abused the anonymity offered by the
certificate. (Details of what constitutes abuse by a user are outside the
scope of the document and are established by TAC CA via a Certification
Policy.) To void the anonymity offered by the two-arty issuance procedure,
both parts of the CA collaborate using a protocol defined in the document.

  The current version of the model supports only RSA-based security
protocols between the two parts of the TAC CA, although the user's
certificate may contain a public key for any algorithm.

Working Group Summary

This document has reached rough WG consensus after considerable debate
over the last 18 months. It is targeted at Experimental status. This work
did not attract much interest from most WG members initially. It addresses
a PKI niche, which some WG members didn't think would ever be of
commercial interest. The document authors were Korean and they had
considerable trouble expressing their ideas in writing, and in a suitable
style for an IETF standard. Steve Kent, my co-chair, agreed to become a
co-author and he re-wrote the document and has coordinated subsequent
revisions. Two WG members provided extensive reviews of the I-D, which
resulted in a number of changes to address technical details. The version
that entered WGLC triggered comments from a few WG members. Changes were
made to address several of these comments, but a suggestion to make a
substantial design change was rejected. Two WG members raised concerns
whether the split-signature technology employed here adds enough security
to merit the increased complexity. However, the principle authors work for
KISA, the Korean Information Security Agency that accredits CAs in that
country. Their judgment that this is a reasonable tradeoff is enough to
merit progression as experimental document. The real proof of the
document's value will be decided based on adoption by CAs, something the
KISA authors say will happen (at least in their country).

Document Quality

There are no know implementations at this time, which is not surprising
for a document targeted at Experimental status. However, the KISA staff
who are the principle authors have indicated that they anticipate at least
one commercial TAC CA (in South Korea) will be forthcoming after an RFC is
published. An organization that chooses to implement the model described
here will be a CA service provider, not a product vendor per se.

RFC Editor Note

This document is being forwarded for publication assuming that the
proposed update to the TLP will be completed by the IETF Trust prior
to completion of the RFC publication process.  If that process does not
terminate successfully, please make the following substitution in 
Appendix A, replacing RFC XXXX with the number assigned to this RFC:

OLD

   DEFINITIONS IMPLICIT TAGS ::=

NEW

   DEFINITIONS IMPLICIT TAGS ::=

--
--   Copyright (c) 2009 IETF Trust and the persons identified as
--   authors of the code.  All rights reserved.
--
--   Redistribution and use in source and binary forms, with or without
--   modification, are permitted provided that the following conditions
--   are met:
--
--   - Redistributions of source code must retain the above copyright
--     notice, this list of conditions and the following disclaimer.
--
--   - Redistributions in binary form must reproduce the above copyright
--     notice, this list of conditions and the following disclaimer in
--     the documentation and/or other materials provided with the
--     distribution.
--
--   - Neither the name of Internet Society, IETF or IETF Trust, nor the
--     names of specific contributors, may be used to endorse or promote
--     products derived from this software without specific prior
--     written permission.
--
--
--
--   THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS
--   'AS IS' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT
--   LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
--   A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT
--   OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
--   SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT
--   LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
--   DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
--   THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
--   (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
--   OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
--
--   This version of the ASN.1 module is part of RFC XXXX;
--   see the RFC itself for full legal notices.
--

From: "Pope, Nick" <[email-masked]>
To: "'Stefan Santesson'" <[email-masked]>, [email-masked]
Cc: Denis Pinkas <[email-masked]>, "Pope, Nick" <[email-masked]>
Subject: RE: Way forward - updating RFC 3161
Date: Wed, 1 Jul 2009 11:47:20 +0100 
Sender: [email-masked]

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C9FA39.4F01D0EE
Content-Type: text/plain

Stefan,

I also agree with the approach of updating RFC 3161.  Changing the model of
RFC 3161 is only going to cause confusion.

The implementation architecture concepts used in the earlier proposal are
already described in RFC 3628  and so I see no need for further steps on
that aspect.

Nick

-----Original Message-----
From: Stefan Santesson [mailto:[email-masked]] 
Sent: 01 July 2009 02:00
To: [email-masked]
Cc: Denis Pinkas; Pope, Nick
Subject: Way forward - updating RFC 3161

We need to resolve how to update RFC 3161 with respect to allowing support
of RFC 5035 (ESSV2)
One particular reason is because ETSI ESI is dependent on progression of
this issue in PKIX.

I would like to open this issue up for debate and then hopefully conclude
this issue, possibly after a straw poll.

My personal opinion, and what I interpret as the general opinion of this
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as
basis for updating rfc 3161. This draft intends to obsolete RFC 3161 and
introduces major changes to terminology and role description to align RFC
3161 with the informational document RFC 3628.

It is problematic to introduce such major changes to a standard that is
widely deployed. It is neither required from a protocol implementation
perspective as these changes are not intended to change any bits on the
wire. The optional usage of ESSV2 does not motivate a total rewrite of the
current standard, but is better handled in an update RFC.

If description of roles and responsibilities that so not change any bits on
the wire need to be clarified in relation to RFC 3628 and RFC 3161, then
this should be handled either as an update to RFC 3628 or as a separate
informational document.

/Stefan 

------_=_NextPart_001_01C9FA39.4F01D0EE
Content-Type: text/html

<html>

<head>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii">

<meta name=Generator content="Microsoft Word 10 (filtered)">
<title>Way forward - updating RFC 3161</title>

<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 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:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{font-family:Arial;
	color:navy;}
@page Section1
	{size:595.3pt 841.9pt;
	margin:72.0pt 90.0pt 72.0pt 90.0pt;}
div.Section1
	{page:Section1;}
-->
</style>

</head>

<body lang=EN-GB link=blue vlink=purple>

<div class=Section1>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Stefan,</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>I also agree with the approach of updating
RFC 3161.&nbsp; Changing the model of RFC 3161 is only going to cause confusion.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>The implementation architecture concepts
used in the earlier proposal are already described in RFC 3628 &nbsp;and so I
see no need for further steps on that aspect.</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>Nick</span></font></p>

<p class=MsoNormal><font size=2 color=navy face=Arial><span style='font-size:
10.0pt;font-family:Arial;color:navy'>&nbsp;</span></font></p>

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

<p class=MsoNormal><font size=2 face=Tahoma><span lang=EN-US style='font-size:
10.0pt;font-family:Tahoma'>-----Original Message-----<br>
<b><span style='font-weight:bold'>From:</span></b> Stefan Santesson
[mailto:[email-masked]] <br>
<b><span style='font-weight:bold'>Sent:</span></b> 01 July 2009 02:00<br>
<b><span style='font-weight:bold'>To:</span></b> [email-masked]<br>
<b><span style='font-weight:bold'>Cc:</span></b> Denis Pinkas; Pope, Nick<br>
<b><span style='font-weight:bold'>Subject:</span></b> Way forward - updating
RFC 3161</span></font></p>

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

<p class=MsoNormal><font size=2 face=Calibri><span style='font-size:11.0pt;
font-family:Calibri'>We need to resolve how to update RFC 3161 with respect to
allowing support of RFC 5035 (ESSV2)<br>
One particular reason is because ETSI ESI is dependent on progression of this
issue in PKIX.<br>
<br>
I would like to open this issue up for debate and then hopefully conclude this
issue, possibly after a straw poll.<br>
<br>
My personal opinion, and what I interpret as the general opinion of this
working group is that we should reject draft-ietf-pkix-rfc3161bis-01 as basis
for updating rfc 3161. This draft intends to obsolete RFC 3161 and introduces
major changes to terminology and role description to align RFC 3161 with the
informational document RFC 3628.<br>
<br>
It is problematic to introduce such major changes to a standard that is widely
deployed. It is neither required from a protocol implementation perspective as
these changes are not intended to change any bits on the wire. The optional
usage of ESSV2 does not motivate a total rewrite of the current standard, but
is better handled in an update RFC.<br>
<br>
If description of roles and responsibilities that so not change any bits on the
wire need to be clarified in relation to RFC 3628 and RFC 3161, then this
should be handled either as an update to RFC 3628 or as a separate
informational document.<br>
<br>
/Stefan</span></font> </p>

</div>

</div>

</body>

</html>

------_=_NextPart_001_01C9FA39.4F01D0EE--

Date: Wed, 01 Jul 2009 11:53:05 +0200
From: Peter Sylvester <[email-masked]>
To: Stefan Santesson <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Denis Pinkas <[email-masked]>, "Pope, Nick" <[email-masked]>
Subject: Re: Way forward - updating RFC 3161
Sender: [email-masked]

Treating Stefan's request as a straw poll: I agree to reject the draft.
No comment about what should be done as updates to other texts.