Re: [IETF-PKIX] Cryptographic binding of certificates tosignatures

[lars.gu.johansson@xxxxxxxxx]

Bob,

BJUENEMAN@novell.com wrote:
>
> Lars, I appreciate your "European" hard-token perspective.
> Certainly, how the keys are generated and how they are
> incorporated into certificates can substantially change the risks.

Right, thanks for your appreciation!

> Just to clarify one thing however. Although I mentioned the
> possibility of changing the SIGNED macro, it was only to
> highlight the original source of the problem. I realize that changing
> the basic definition at this time is probably not a viable
> possibility.
>
> However, my final recommendation and conclusion was that we
> consider creating a new set of signature algorithm IDs that would
> end up using RSA, DSA, etc., but would also include additional
> information such as the issuerName and serial number, or perhaps
> just a hash of the certificate, so that the certificate to be used
> is irrevocably tied to the signed text.

Ok, so that would allow some protocols to switch over by using the
new set of algorithm IDs while others can continue using the old ones.

That doesn't change my original criticism however. What may seem
as an improvement in flexibility is really just going back to the original
situation (with some "safe" protocols using the new set of algorithm
IDs and other protocols still being "unsafe"). Why then not leave this
to the protocol designers or, as I suggested, to the key holder and
relying party?

> I also mention the desirability of including some additional information
> such as date/time and possibly the identity of the platform on which
> the signature was applied, for audit purposes.

I can think of many different information fileds that can be useful. Let me
just give you one example: Charcter set coding. Suppose that I sign a
document and include my certificate serial number '123' and later
discover that I'd rather liked to have used the certificate with serial
number '342'. Well then I could try to claim in court that I actually used
the special "Swahilian ASCII coding" (or something like that), where
3=49, 4=50 and 2=51. (There's no limit to my imagination of the usefulness
of this technique ;-).

My point is that we shouldn't put any restrictions to what must be included
in a signature (unless it's really cryptographically relevant like randomness
and formatting for example). If we do, then we'll most certainly run in to the
situation where we find that the standard is too limited. Again, let
this thing be
taken care of by the application designers!

> (You might be particularly interested in the later, from your hard-token
> perspective. Assuming that the token only generates the signature, and
> maybe the message digest that goes into it, the token has no way of
> knowing what the user saw on the screen that was supposed to be
> signed, as opposed to what the application actually presented to be signed.
> Unless the token is limited to only signing once per insertion, a rogue
> merchant could cause the token to sign all sorts of things, while the
> user thinks that she is only buying a dishrag. Including an authenticated
> identification of the platform would help point a smoking gun in such cases.)

Actually, I'm not interested in that possibility. My primary interest
is to have a
common PKI for both smart cards and soft tokens. If smart cards should use
a different signature algorithm than everyone else, it would be a bad thing.

> Other people may have their own pet ideas which should be considered.
> For example, I foresee a time in the relatively near future where
biometrics will
> be combined with digital signatures to circumvent some of the control issues
> that neither a password encrypted key nor a smart token solve, since
either can
> be given away.  It would no doubt be very useful to incorporate the biometric
> indicia into the signature itself, so that it would later be
validated against
> the biometric template included in the certificate. Without
supporting such a
> basic mechanism now, while the industry is still in the process of
writing lots of
> new applications, adding such features would require modifications to
a very large
> number of individual applications -- an almost hopeless task.

Spooky, indeed!

> But I'm not trying at this time to suggest precisely what ancillary
information
> should be included. We are still trying to sort out whether it should be
> done at all. Of course, even if a new signature algorithm ID is
> defined, it doesn't have to be used, so it would be optional from that
> standpoint. For the sake of interoperability, however, it would be a new
> algorithm that would have to be widely supported, unless we can figure
> out a mechanism for making the additional parameters transparent.
>
> I do believe that specifying the suite of signature algorithms that are to be
> supported is one of the functions of this group, so I believe the
discussion is
> appropriate for this list.

Well, I disagree on this point. Let's have the standards finished as soon as
possible so we can start using them. They may not be perfect but we must
remember that there's no such thing as absolute security (unless of course
you don't communicate at all :-).

Kind regards,
/Lars Johansson
Sweden Post