Re: X.509

[pgut001%cs.auckland.ac.nz@localhost (Peter Gutmann)]

Roumen Petrov <openssh%roumenpetrov.info@localhost> writes:
>Peter Gutmann wrote:
>> Further to my previous comments, the text in the Implementation Considerations
>> section seems a bit misplaced.  Firstly, it's already subsumed by the "refer
>> to PKI standards" requirement in the Security Considerations, so it's
>> redundant.  Secondly, I would both hope that any implementation that doesn't
>> implement a verification algorithm would fail to verify the certificate that
>> uses it, and can't really see why this would be singled out for special
>> attention when there are lots of other things that also need to be checked.
>
>It is possible simple implementation to compare public key extracted from
>certificate sent with keys from its configuration and if they match to accept
>connection.

Sure, but that's a specific local policy issue, there are (literally) a
million other ways to do this and I'm not sure why the RFC draft is choosing
to focus on this one particular issue.

>>Finally, to be nit-picky, you need to verify up to a trust anchor, which
>>isn't necessarily "all the certificates in the chain".
>
>Yes verification should be described in RFC3280. Only the direction is
>opposite - valid path (chain) start from trust anchor .

Only if you've swallowed the spaghetti-PKI red-pill lunacy that path
construction is top-down, which means you have to solve an NP-hard graph
theory problem to verify your cert(s) (at one PKI talk, a top-down path-
construction advocate described, with a totally straight face, how his path-
construction software had run for three days without terminating, until he
killed the process).

>You can test my implementation based on openssh and diff files on
>http://roumenpetrov.info/openssh/download.html .

Thanks.

Peter.