Re: Q on X.509 authentication in SSH draft

[Jan Pechanec <Jan.Pechanec%Sun.COM@localhost>]

On Thu, 3 Jan 2008, Jan Pechanec wrote:

	hi, maybe sending this while many of us were still on holiday wasn't 
the best idea.

	any thoughts on that issue please?

	another option would be to maintain the same number of responses to 
the number of certificates sent, and have them in two different lists as the 
current draft suggests. However, any response could be just an empty string. 
That would be another way to easily recognize which response is supposed to 
belong to which certificate, without checking certID field in the response.

	thanks, Jan.

>
>	hi, in 4.1 section of draft-ietf-secsh-x509-03.txt[1], where 
>"x509v3-sign" format is defined, there is this sentence:
>
>>The first certificate in the list MUST be the end-entity one, and any
>>other certificates MUST be part of the end-entity certificate's path.
>
>	depending on CA policy, not all certificates need to be accompanied 
>with an OCSP response, but could it be assumed that OCSP response list is 
>"sorted" according to certificates supplied? It means that one could just go 
>through the certificate list and check the first not yet processed OCSP 
>response for match whether it is the only SingleResponse in OCSP response or 
>the first unprocessed SingleResponse as part of one OCSP response.
>
>	I also assume that the certificate list is "sorted" but neither that 
>is explicitly defined there and I think it should be.
>
>	I don't see any problem for the party being authenticated to sent an 
>already sorted list of OCSP responses. Well, I could live with the unsorted 
>list, too, but the sorted list is just more efficient if we consider a long 
>validation path. What is more important I think is that it would be nice if 
>this is explicitly specified there.
>
>
>	anyway, given all the options how it could be done, I'm thinking 
>that it would be simpler to use a pair of strings for every certificate - 
>the certificate itself and an optional OCSP response which could be an empty 
>string. And it would be sorted for use of PKIX validation path algorithm. It 
>wouldn't increase the length of the data much in comparison to the length of 
>the certificates and one could easily separate them into two sorted list if 
>needed.
>
>	string "x509v3-sign"
>	uint32  number of certificate/OCSP response pairs
>	string  DER encoded X.509v3 certificate data
>	string  optional OCSP response data
>	string  DER encoded X.509v3 certificate data
>	string  optional OCSP response data
>	...
>
>	
>	thanks, Jan.
>
>[1] http://www3.ietf.org/proceedings/06mar/IDs/draft-ietf-secsh-x509-03.txt
>
>

-- 
Jan Pechanec