RE: Feedback on draft-igoe-secsh-x509v3-01

["Igoe, Kevin M." <kmigoe%nsa.gov@localhost>]

For sake of completeness, let me take a stab at what the
I think is meant by the phrase "prepared to receive" in this
context.

"Prapared to receive" means the server is able to identify the
type digital signature used within each cert in the certificate 
chain and decide if it is capable of verfiying this flavor of  
digital signature.

If either 
	1) putative chain of certs isn't properly formed
	2) the root authority is unaccpetable
	3) the server you isn't able to handle one or more
         of the flavors of digital signatures being used
	4) one or more of the signatures is invalid
then the server should send a SSH_MSG_USERAUTH_FAILURE message.

Sadly, RFC 4252 highly constrains the format of a
SSH_MSG_USERAUTH_FAILURE
message, limiting he feedback that can be given to the user as to why
their authentication has failed.

> 5.1.  Responses to Authentication Requests
>    If the server rejects the authentication request, it MUST respond
>    with the following:
> 
>       byte         SSH_MSG_USERAUTH_FAILURE
>       name-list    authentications that can continue
>       boolean      partial success
> 
>    The 'authentications that can continue' is a comma-separated name-
>    list of authentication 'method name' values that may productively
>    continue the authentication dialog.

 
> -----Original Message-----
> From: ietf-ssh-owner%NetBSD.org@localhost 
> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of der Mouse
> Sent: Tuesday, March 30, 2010 1:27 PM
> To: ietf-ssh%NetBSD.org@localhost
> Subject: Re: Feedback on draft-igoe-secsh-x509v3-01
> 
> > I'd like to soften the "Verifiers MUST" in the second paragraph to 
> > "Verifiers SHOULD".  [...]
> >>   Verifiers MUST be prepared to receive certificate chains that use
> >>   algorithms that were not listed [...]
> 
> I see no reason to soften this.  Being prepared to receive 
> certificate chains is not the same thing as being prepared to 
> accept, verify, and authenticate using them.
> 
> Or were you talking about a different paragraph and thus a 
> different MUST?
> 
> /~\ The ASCII				  Mouse
> \ / Ribbon Campaign
>  X  Against HTML		mouse%rodents-montreal.org@localhost
> / \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B
>