[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Signature format and smart cards
Then the solution is to negotiate signature encoding type as well.
Clearly, the best solution is to add signature encoding type to the cert and
cert request payload headers. We cannot do this. So I again propose to
flag the oid-ful format with a 1 in the reserved field of these headers
until ipsecond can fix this.
bs
> -----Original Message-----
> From: Michael C. Richardson [SMTP:mcr@sandelman.ottawa.on.ca]
> Sent: Wednesday, July 08, 1998 10:11 AM
> To: ipsec@tis.com
> Subject: Re: Signature format and smart cards
>
> -----BEGIN PGP SIGNED MESSAGE-----
>
>
> >>>>> "Brian" == Brian Swander <briansw@microsoft.com> writes:
>
> Brian> This is not a new auth method, but an existing auth method with
> a
> Brian> different signature format. The analogous example is the cert
> Brian> payload. There are different encoding types for certs and we
> Brian> determine which we are using by a field in the certificate
> payload
> Brian> header. The obvious choice is to do the similar thing for the
> Brian> signature payload instead of unnecessarily expanding the
> Brian> authentication methods available.
>
> No, it isn't obvious to me.
> The signatures are not compatible. If my smart card/software refuses to
> sign
> using the OID, and yours can not sign without the OID, we can not
> communicate.
> To the user, this is exactly the same as if you had DSS and I had RSA.
>
> Certificates are *requested* by format, and if you don't get something
> you understand, the failure mode is clear. Further, you may not even
> need that certificate, and the ability to send multiple certificates
> allows
> one to send certificates in multiple formats.
>
> Brian> I agree that we should change the signature header to include
> this
> Brian> field instead of using the reserved section, but that will be
> an
> Brian> ipsecond issue.
>
> No. If you want to use the reserved field, it is an IPsecond issue as
> well.
>
> Brian> Implementations that choose not to recognize this flag will
> fail
> Brian> because the signature is in the wrong format. It is obviously
> up
>
> Which causes the user/administator to spend hours trying to determine
> why the public keys/certificates are not configured right.
> What you suggest leads to non-interoperable systems. Maybe that
> doesn't bother you.
>
> The protocol has a clear place for vendor specific codes (65001-65535
> for signature algorithms). Use it.
>
> :!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
>
> iQB1AwUBNaOoMdiXVu0RiA21AQGTkAMApweMPF8lczmqKkZXZ9E3SuTTEI+FA9JY
> 7z0vPbbpDRaFDI6LSlc1tigtFawYBYG/IjWUWH4PbcXDJIaMZnico7Kl+C0xMNMS
> 75ArT7oX9UG+IyKTIgBO2P7qQlKDJHpB
> =WqJE
> -----END PGP SIGNATURE-----
Follow-Ups: