[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Signature format and smart cards
This is not a new auth method, but an existing auth method with a different
signature format. The analogous example is the cert payload. There are
different encoding types for certs and we determine which we are using by a
field in the certificate payload header. The obvious choice is to do the
similar thing for the signature payload instead of unnecessarily expanding
the authentication methods available.
I agree that we should change the signature header to include this field
instead of using the reserved section, but that will be an ipsecond issue.
Implementations that choose not to recognize this flag will fail because the
signature is in the wrong format. It is obviously up to those
implementations to signal whatever they like to whomever they like. They
have all the necessary information whether they choose to recognize the flag
or not.
bs
> -----Original Message-----
> From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca]
> Sent: Tuesday, July 07, 1998 3:51 PM
> To: ipsec@tis.com
> Subject: Re: Signature format and smart cards
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Brian" == Brian Swander <briansw@microsoft.com> writes:
> Brian> It is unlikely that all the vendors will ship using our format,
> Brian> and at the same time, IKE needs to be able to use certs from
> smart
> Brian> cards.
>
> Brian> I propose:
>
> Brian> Set the reserved field of the sig_payload header to 1 to signal
> Brian> standard pkcs1 with the OID, 0 otherwise.
>
> That is a silly thing to do.
> It doesn't nothing to help interopability, nor signals to people who
> haven't implemented this "hack" why the signatures fail.
>
> Instead, you need to define a new signature format, as if it were
> a totally different format. From isakmp-oakley-08:
>
> - Authentication Method
> pre-shared key 1
> DSS signatures 2
> RSA signatures 3
> Encryption with RSA 4
> Revised encryption with RSA 5
> RSA signatures with OID 6 <--add
>
> values 6-65000 are reserved to IANA. Values 65001-65535 are for
> private use among mutually consenting parties.
>
> :!mcr!: | Sandelman Software Works Corporation, Ottawa, ON
>
> Michael Richardson | SSH IPsec: http://www.ssh.fi/. Secure,
> strong, international
> Personal: <A
> HREF="http://www.sandelman.ottawa.on.ca/People/Michael_Richardson/Bio.html
> ">mcr@sandelman.ottawa.on.ca</A>. PGP key available.
> Corporate: <A
> HREF="http://www.sandelman.ottawa.on.ca/SSW/">sales@sandelman.ottawa.on.ca
> </A>.
>
>
>
>
> -----BEGIN PGP SIGNATURE-----
> Version: 2.6.3ia
> Charset: latin1
> Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
>
> iQB1AwUBNaKmWtiXVu0RiA21AQG7nwL/TIclOU31I3CVIZG8nonN01TzGj7D6LJz
> BE9roolxmgZMsh1YGm4QyQhZP9ft7xXGmqe2N7jsH9DvodGWCiKdIH/+dT8R1L4g
> k377FEmqvdJ9ndvnBW3c2wFXQ94kNpbw
> =9sxX
> -----END PGP SIGNATURE-----
Follow-Ups: