Re: Comments on the PKIX Roadmap

[Denis Pinkas <Denis.Pinkas@xxxxxxxx>]

Sean,

Before packing to Washington, a short answer. I have deleted some
stuff to make this answer more readable.

> Denis,
> 
> Thanks for the comments.  Mine are in line.
> 
> Denis Pinkas wrote:
> 
> > Comments on the PKIX Roadmap <draft-ietf-pkix-roadmap-04.txt>
> > I would propose instead:

(...)

> > [DVCS] allows to verify and assert the validity of all signatures
> > attached to the signed document using all appropriate status
> > information and PKCs or to verify and assert the validity of one or
> > more PKCs at the specified time.
> >
> 
> Okay I can add this.  Other have commented in private e-mail to expand
> the DVCS description to include:
> 
> - delegation of verification to trustworthy servers
> - Chaining of verifications
> - The DVCS not only validates the signature of the document,  it checks
> the validity of a document.

For the last sentence, I do not think so. The content of the signed
part is not "validated"

(...)

> Okay except for the last sentence.  I thought [ETNPT] gave you a format
> to store the information locally (like on your HD).  I wasn't sure if
> TSP provided the same function (thought I guess it could if you stored
> the message).  If you think the goal for [ETNPT] needs to be clarified
> we should do that in a separate e-mail thread about ETNPT and not just
> put it in the roadmap.

I will do so.

> > Page 28: Section 4.5. Change the title into: "Time Stamp Protocols"
> >
> 
> Somebody else suggested "Time Stamping and Data Validation and
> Certification Server Protocols" can we use that instead?

The current title of TSP does not contains "and Data Validation and
Certification Server Protocols". Having TSP addressed separately
seems more appropriate.

> > Page 39: Section on POP. It should be noticed that POP is NOT always
> > needed. For some (old) "poorly designed" protocols, POP is needed
> > when the SAME key is being used for authentication purposes and non
> > repudiation purposes. Basically, if the protocol makes sure that the
> > identifier of the public key certificate is protected by the end
> > user signature, then POP does not need to be performed by the CA.
> > For the case of encryption, see the proposed text replacement. Here
> > is a full text replacement for that topic:
> >
> 
> In general, I have no real concerns with what you propose just a few
> questions.

(...)

> >
> > Protection can be gained by having Alice, as the true signer of the
> > transaction, include in the signed information her PKC or an
> > identifier of her PKC (e.g., a hash of her PKC). This makes
> > impossible for Mal to claim authorship because he does not know the
> > private key from Alice and thus is unable to include his certificate
> > under the signature.
> 
> The last sentence says "impossible."  What it used to say was:
> 
> This might make it more difficult for Mal to claim authorship - he would
> have to assert that he incorrectly included Alice's PKC, rather than his
> own. However, it would not stop Alice from falsely repudiating her
> actions. Since the PKC itself is a public item, Mal indeed could have
> inserted Alice's PKC into the signed transaction, and thus its presence
> does not indicate that Alice was the one who participated in the
> now-repudiated transaction. The only reliable way to stop this attack is
> to require that Mal prove he possesses X before his PKC is issued.
> 
> What was it that you didn't like from the previous text?

"Impossible " means impossible, not "more difficult". :-)

> > The adequate protection may be obtained in the general case, by
> > mandating the inclusion of a reference of the certificate every time
> > a signature (or non repudiation) key is being used in a protocol.
> >
> > However, because all the protocols were not doing so, a conservative
> > measure has been taken by requesting POP to be performed by CAs. It
> > should thus be understood, that this measure is not strictly
> > necessary and is only a temporary measure to make old protocols
> > secure. New protocols or data formats are being developed. If the
> > key being used is always used in a context where the identifier of
> > the certificate is included in the protocol, then POP by the CA is
> > not necessary. The inclusion of the identifier of the certificate in
> > the protocol or data format may be understood as POP being performed
> > at the transaction time rather than by the CA, at the registration
> > time of the user in the PKI.
> 
> The text indicating that the need for POP for signing keys not used for
> non-repudiation was removed.  What didn't you like about it?

The above is valid for all keys, as soon as the identifier of the
certificate may be closely tied to the signature key.

> I think the rest of the POP rewrite looks fine.

(...)

Regards,

Denis