Re: AW: self-signed TSA [Was Re: Private Key Cloning]

[Aram Perez <aram@xxxxxxxxxxx>]

Hi Michael,

If I take your statements/conclusions below to their extreme, then anytime
PKIX comes up with a new service that uses digital signatures, that service
would have to issue its own self-signed certificates. I don't see the OCSP
folks requesting their own self-signed certificates.

Regards,
Aram Perez

>> 
>> I don't agree.  As the service provider, why do I *have* to deal with
>> the management of two private keys.  It's way more than syntax.
>> 
>> We don't need to "push" anything.  We need to not prohibit it.
>> /r$
>> 
> 
> I fully agree with that.
> 
> Guys,
> 
> << I feel that I've said all I had to say on the subject. In this mail I'll
> try to put together a little summary of my position, which I know is
> supported by a number of the list members. It was taking too much and too
> long - this message will be the last from me on self-signed TSA certs (do I
> see happy smiles :)? Denis, it is really up to you now - put it on vote, or
> forget. >>
> 
> I (quite frankly) fail to understand the rational for the draft to introduce
> limitations which necessitate extra entities and potentially more complex
> environment for all involved parties. All for a sake of extra purity of a
> concept, which is already pure enough. Probably my position is too much
> 'engineering', but this is what I am, sorry.
> 
> An example first:
> Imagine some Business_Domain_Managing_Authority (BDMA) that wants to deploy
> a TSA service for its members. Would it be Ok that the members express their
> trust directly to the TSA? I guess so.
> 
> With the client's trust expressed directly to the TSA cert, it is irrelevant
> if the TSA cert was self-signed or CA-signed. Referring to the arguments in
> favor of signing by CA - yes, I agree that there are benefits, thank you. It
> is all perfect with the assumption that there IS a CA around, or at least a
> business has a need for a CA.
> 
> Now, can anybody explain the BDMA's manager (a stubborn and slow guy he is
> indeed :) why the organisation has to buy/setup/employ a CA, if everything
> that they will ever need is just a TSA?
> 
> << I know that the previous sentence may get me sacked from Baltimore, which
> main business is selling CAs. :) So the standard disclaimer is right here.
>>> 
> 
> Mind you, out-of-band TSA cert delivery is as complex, or as simple, as the
> one for distributing a CA's cert, should it exist.
> 
> As a conclusion:
> Using self-signed TSA certs should be an internal matter for each domain,
> each TSA, subject to specific policy and national regulations. And a hell
> lot more. Therefore, the draft should not encourage self-signed TSA certs,
> neither it should prohibit them. It should be neutral and stay away from
> that slippery subject.
> 
> And it is not far from what the current draft is about, as it seems.
> 
> A minor fix- a sentence for the security considerations section would be
> something like:
> "The TSA private key must be generated and used ONLY for signing timestamps,
> and possibly for internal key/certificate management operations such as
> P-O-P or self-signing."
> 
> Best regards
> Michael
>