Subject: RE: Way forward - updating RFC 3161

From: "Pope, Nick" <[email-masked]>
Date: Wed, 1 Jul 2009 11:47:20 +0100

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

---

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

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:

> already described in RFC 3628  and so I see no need for further steps on that
> aspect.
>  
> Nick
>  
> 
> 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.
> 
> 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.
> 
> 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 
>

---

From: "Denis Pinkas"<[email-masked]>
Date: Fri, 10 Jul 2009 15:55:38 +0200

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.

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.

     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.

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

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. 

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. 

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

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.

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.

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

The key used to sign TSTs is not the key from a TSA, but the key from a TSU.

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. 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. 
However, it is necessary to be able to know the name of the TSA when looking at the 
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 
   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'.

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.

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.

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.

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.

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.

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.

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.

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

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. 

Denis
----- Message reçu ----- 
De : Stefan Santesson 
À : Pope,Nick,ietf-pkix 
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 that we will have a strong consensus for just making a short update document.

/Stefan

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

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 19 Jul 2009 14:39:23 +0200

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 ³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. 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 part
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:

>> De  : Stefan Santesson <mailto :[email-masked]>
>>  
>> À  : Pope,Nick,ietf-pkix <mailto
>> :[email-masked],[email-masked]>
>>

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 19 Jul 2009 15:50:24 +0200

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

---

From: Stefan Santesson <[email-masked]>
Date: Sun, 19 Jul 2009 16:14:41 +0200

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

---

From: Peter Sylvester <[email-masked]>
Date: Sun, 19 Jul 2009 19:21:45 +0200

>     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 major differences from RFC 3161 [RFC3161] are summarized on
>     page 3 of the draft and are listed below:
>
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.
>              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
And confusion with the "tsa" field in tstinfo added.
>          5 - a new normative ASN1 module to refer to the ASN.1 modules
Whow, that indeed very important.
>     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.
>     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.
>     15 years and should not be changed earlier, unless strictly needed.
I am not sure what you mean by CA here.
>     that is managed by an Authority called a TSA (Time-Stamping
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
IMO  'the key from a TSA/U' is not a sufficiently well defined
definition to make a distinction.

>     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,
and, where is the beef?
>     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?
>       to provide the time-stamp token by returning a pkiStatusInfo of
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.
>     SigningCertificate attribute.
Rejected. The ESSCertId MUST be provided. An ESSCertIDV2 MAY be 
optionally added.
>       The serialNumber field is an integer assigned by the TSU to each
This seems an overspecification. nothing is wrong, if a global TSA 
concentrator
allocates unique serialnumbers for its backend signing machines.
>       genTime is the time at which the time-stamp token has been
Idem. In fact, the text could say: Indicates the time that a TSA is 
willing to
assert.
>       The purpose of the tsu field is to give a hint in identifying the
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

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

>     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.
>     An update would have to advantage to keep the magic number 3161
I think that was already discussed. no replacement.
>     should be addressed to align RFC 3161 with the documents issued
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

---

From: Stephen Wilson <[email-masked]>
Date: Mon, 20 Jul 2009 06:40:03 +1000

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

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 20 Jul 2009 14:02:14 +1200

Stephen Wilson <[email-masked]> writes:

>should only be responsible for the quality of the certificates (cheques) but
>not their content.
>

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.

---

From: Stephen Wilson <[email-masked]>
Date: Mon, 20 Jul 2009 12:45:56 +1000

Peter Gutmann wrote:
>> 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]>
Date: Mon, 20 Jul 2009 07:34:28 +0300

Peter Gutmann wrote:

>>should only be responsible for the quality of the certificates (cheques) >but
>>not their content.
>>
>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.
>

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 upon 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 blobs 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 the issuing process. I don't see that happening in the contexts discussed on PKIX.

Email secured by Check Point

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 20 Jul 2009 09:14:15 +0200

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:

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

---

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

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:

>>>> but

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 20 Jul 2009 20:54:29 +1200

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.

---

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

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

---

From: Stephen Wilson <[email-masked]>
Date: Mon, 20 Jul 2009 20:06:50 +1000

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

---

From: Peter Gutmann <[email-masked]>
Date: Mon, 20 Jul 2009 22:56:23 +1200

>meaning and purpose is unclear to me.

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

Peter.

---

From: Stefan Santesson <[email-masked]>
Date: Mon, 20 Jul 2009 12:55:18 +0200

Hi Stephen,

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

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

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.

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

> IDtrust conference in 2008.

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