Johannes Merkle writes:
> Nice work, the wording is really improved. However, I still have two
> comments:
>
> 1. The wording in A.4 is confusing.
>
> With RSASSA-PSS, the algorithm object identifier is always id-RSASSA-
> PSS, but the hash function is taken from the optional parameters, and
> is required.
>
> It is not the hash function or the optional parameters that are
> required but the OID id-RSASSA-PSS. Secondly, the "but" in the
> second part of the sentence indicates some contrast but I don't see
> one. Furthermore, not only the hash function is determined from the
> parameters but also the other options for the padding.
>
> Why not changing the text to
>
> With RSASSA-PSS, the algorithm object identifier must always be
> id-RSASSA-PSS, and the hash function and padding parameters are
> conveyed in the optional parameters.
Changed to:
With RSASSA-PSS, the algorithm object identifier must always
be id-RSASSA-PSS, and the hash function and padding parameters
are conveyed in the parameters (which are not optional in this
case). See <xref target="RFC4055"/> for more information.
In the RSASSA-PSS the parameters are required, but they can be empty,
so they are not optional in this case.
> 2. The wording in A.4.1 is also not unambiguous:
>
> Parameters are empty, but the ASN.1 part of the sequence must be
> there. This means default parameters are used (same as the next
> example).
>
> Here "next example" does not refer to the example following
> immediately after this paragraph but to the example in the next
> section. A reference to A.4.2 should be included.
Changed to:
Parameters are empty, but the ASN.1 part of the sequence must
be present. This means default parameters are used.
I.e removed the reference to next example.
--
[email protected]
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
