>
> How about standardizing just one more authentication method?
>
> Call it "public key signature" or some such, and make the signing algorithm
> depend on the public key in the CERT payload.
>
> If it's RSA, go by bit strength:
> - <=1024 - SHA-1 with RSA
> - 1024<x<=2048 - SHA2-256 with RSA
> - 2048<x<=4096 - SHA2-384 with RSA
> - >4096 - SHA2-512 with RSA
>
> DSA - always SHA-1
>
> ECDSA will be defined by curve. The three NIST curves that everyone uses
> already have hashes associated with them. Any new curve would have to specify
> the signature algorithm in the same document.
>
Adding new methods giving more flexibility seems a good approach but,
unfortunately, your proposal would not offer the
flexibility you aim at:
The Subject Public Key Algorithm OID typically used in certs are defined in RFC
3279 and these do not specify the
signature algorithm. For RSA, the RSAPublicKey OID allows both
RSASSA-PKCS1-v1_5 and RSASSA-PSS (currently, only an
authentication method for the former is specified but the latter is definitely
to be used in the future). For
RSASSA-PSS, more specific public key types are specified in RFC 4055 but use of
the old key identifiers is still
permitted and very common. In case of ECC keys, the identifier id-ecPublicKey
does also not specify the signature
algorithm.
Thus, unless you want to enforce usage of the id-RSASSA-PSS OID from RFC 4055
for (future) RSASA-PSS keys and restrict
ECC keys to ECDSA (thus, not allowing the future use any other EC-based
signature algorithm apart from ECDSA), any new
authentication method should at least specify the signature algorithm (e.g.
RSASSA-PKCS1-v1_5, RSASSA-PSS, ECDSA). As
Tero suggested, the specification of the domain parameters and hash function
could possibly be required using the 3
bytes of reserved data in the authentication payload immediately after the auth
method.
It appears to me that an enhanced flexibility is also needed for the existing
RSASSA-PKCS1-v1_5 method as soon as other
hash functions than SH-1 are to be used. RFC 5996 is not very convincing in its
description how this can be accomplished:
--- begin extract ---
Implementations can use the
certificates received from a given peer as a hint for selecting a
mutually understood hash function for the AUTH payload signature.
Note, however, that the hash algorithm used in the AUTH payload
signature doesn't have to be the same as any hash algorithm(s)
used in the certificate(s).
--- end extract ---
So implementations are supposed to use the hash algo used by the CA (!) as an
indication on what the peer uses, although
this does not need to be reliable? This seems to me as a lack of proper
specification.
Johannes
> Since the same certificate can be used with both the old authentication
> method and the new, we'd have to signal support in a Notify, and that Notify
> could have bits for indicating support for other signature algorithms such as
> those that go with SHA3.
>
> Wouldn't this make adding future curves and other signature variants easier?
>
> Yoav
>
>
--
Mit freundlichen Grüßen,
Johannes Merkle
--
Dr. Johannes Merkle
Principal
Biometrie & Hoheitliche Dokumente
secunet Security Networks AG
Mergenthaler Allee 77
65760 Eschborn
Germany
Telefon +49 201 54 54-3091
Telefax +49 201 54 54-1325
Mobil +49 175 2224439
[email protected]
www.secunet.com
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
