[Ssh] Re: I-D Action: draft-ietf-sshm-cert-00.txt

[Tero Kivinen <[e-mail]>]

Roumen Petrov writes:
> На 27.04.26 г. в 21:12, Tero Kivinen написа:
> >>[]
> > It does not do that, or more exactly it does even more. My
> > understanding is that the existing implementations use
> > "[e-mail]" name not the "ssh-rsa-cert" name.
> 
>    Names that do not contain an at-sign ("@") are reserved to be
>    assigned by IETF CONSENSUS.  Examples include "3des-cbc", "sha-1",
>    "hmac-sha1", and "zlib" (the doublequotes are not part of the
>    name).  Names of this format are only valid if they are first
>    registered with the IANA.  Registered names MUST NOT contain an
>    at-sign ("@"), comma (","), whitespace, control characters (ASCII
>    codes 32 or less), or the ASCII code 127 (DEL).  Names are case-
>    sensitive, and MUST NOT be longer than 64 characters.
> 
> Doesn't this working group want to follow "Secure Shell (SSH)
> protocol architecture"? 

This text is not relevat as the name does contain '@'. The second
bullet is relevant:

   o  Anyone can define additional algorithms or methods by using names
      in the format name@domainname, e.g., "[e-mail]".
      The format of the part preceding the at-sign is not specified;
      however, these names MUST be printable US-ASCII strings, and MUST
      NOT contain the comma character (","), whitespace, control
      characters (ASCII codes 32 or less), or the ASCII code 127 (DEL).
      They MUST have only a single at-sign in them.  The part following
      the at-sign MUST be a valid, fully qualified domain name [RFC1034]
      controlled by the person or organization defining the name.  Names
      are case-sensitive, and MUST NOT be longer than 64 characters.  It
      is up to each domain how it manages its local namespace.  It
      should be noted that these names resemble STD 11 [RFC0822] email
      addresses.  This is purely coincidental and has nothing to do with
      STD 11 [RFC0822].

The name [e-mail] follows rules specified there.
Nothing in the architecture says we can't use IETF CONSENSUS to
allocate these types of names too if we want (there is no need, but we
can use it if we like). We are documenting protocol defined by
external body and making it backward compatible with that one, and
that is the reason we want to keep the same name.

We might need to create new sub registry Public Key Algorithm Names
for commonly used private space names for public key algorithm names,
as iana registry do say that in existing registry the names MUST NOT
contain at-sign.
-- 
[e-mail]