Re: Registered algorithm vs supported algorithm

On Fri, Jan 31, 2014 at 10:18 PM, Jim Schaad <ietf@augustcellars.com> wrote:

> When doing  generate call, I am not sure where the correct location for
> putting in a failure would go for an algorithm that is registered but is
> not implemented.
>
>
>
> The normalization function does not appear to check that the algorithm is
> supported – only that a recognized alias is given.  I would assume that
> this should fail with InvalidAlgorithmError if a recognized but not
> implemented name is given (as this would be the default with a new alias).
>
>
>
> However if a dictionary I given, there is no check there that name is in
> the implemented table.    The generate function would appear to say that a
> registered, but unimplemented algorithm would be treated as a
> non-registered algorithm as the check for support would fail and thus
> return NotSupportError.
>
>
>
> It would be nice of the same error would be returned in both cases,
> especially if I can normalize all of the algorithms at the time of
> implementation – but wanted to return a not supported error in the case it
> was not implemented.  I am not sure if this is reasonable behavior or not.
>
>
>
> Jim
>
>
>

I'm not sure I follow why you'd want the same error for an invalid name -
eg: AES-PCM - versus a string in the spec but not supportable by a UA. The
latter is something that MAY be user actionable (for example: an admin may
have disabled AES-GCM in an operating systems' crypto implementation, but
the OS itself does support GCM), while the former is only actionable by
either changing UAs (eg: if AES-PCM was some vendor-specific algorithm) or
fixing the typo.