headers
Jan Pechanec | 3 Jan 2008 17:53
Picon

Q on X.509 authentication in SSH draft


	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.
(Continue reading)

Permalink | Reply | 501 comments |
headers
Jan Pechanec | 10 Jan 2008 16:09
Picon

Re: Q on X.509 authentication in SSH draft

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
(Continue reading)

Permalink | Reply | 501 comments |

Gmane