IETF-SSH archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: Still more feedback on draft-igoe-secsh-x509v3-01



In that case, if no one else objects, lets
change the wording to make it clear that
the chain MUST be included, and MUST be
complete except for the root certificate.

Thanks,

Joseph

On 4/5/2010 07:02, Igoe, Kevin M. wrote:
>> I know I sometimes mark an intermediate certificate as 
>> trusted in testing.  Is this something that happens in the real world?
>>
> 
> I haven't seen this & neither have the folks I've asked about it.
> 
> 
>> -----Original Message-----
>> From: Joseph Galbraith [mailto:galb-list%vandyke.com@localhost] 
>> Sent: Saturday, April 03, 2010 10:56 AM
>> To: Igoe, Kevin M.
>> Cc: ietf-ssh%NetBSD.org@localhost; Douglas Stebila
>> Subject: Re: Still more feedback on draft-igoe-secsh-x509v3-01
>>
>> On 4/1/2010 08:18, Igoe, Kevin M. wrote:
>>>> o The chain encoded MAY be incomplete; it is usually not
>>>>   necessary to include the self-signed certificate specifying
>>>>   the root authority.
>>>>
>>>>   It is NOT REQUIRED to specify any certificates other than
>>>>   the senders certificate.  If the verifier has a trust anchor
>>>>   that is not the self signed root, these other certificates may
>>>>   not be needed.  However, omitting certificates from the chain
>>>>   may make it more likely that certificate verification will fail
>>>>   because the verifier is not able to build a chain to a trusted
>>>>   anchor.
>>>
>>> I'd like our X.509v3 draft to be a "gold standard" for 
>> authentication 
>>> and would prefer an unbroken certificate chain leading back 
>> to a root 
>>> authority. The chain of certs moves the risk that the user's public 
>>> key is bogus down the chain to the risk that the root's 
>> public key is 
>>> bogus.  One can then take measures to mitigate the risk 
>> that the root 
>>> public key is bogus, these measures being well outside the scope of 
>>> this document.
>>>
>>> P.S. Having the root self-sign their cert isn't very 
>> effective, whence 
>>> it being optional.
>>
>> I know I sometimes mark an intermediate certificate as 
>> trusted in testing.  Is this something that happens in the real world?
>>
>> Thanks,
>>
>> Joseph
>>
>>>> -----Original Message-----
>>>> From: ietf-ssh-owner%NetBSD.org@localhost
>>>> [mailto:ietf-ssh-owner%NetBSD.org@localhost] On Behalf Of Joseph Galbraith
>>>> Sent: Wednesday, March 31, 2010 8:55 PM
>>>> To: ietf-ssh%NetBSD.org@localhost
>>>> Subject: Still more feedback on draft-igoe-secsh-x509v3-01
>>>>
>>>> In section 2.  X.509 Version 3 Certificates, we have:
>>>>
>>>>>    o  The self-signed certificate specifying the root
>>>> authority MAY be
>>>>>       omitted.
>>>>
>>>> which seems to indicate that all certificates except the 
>> self-signed 
>>>> certificate at the root MUST be included.
>>>>
>>>> I'm not sure that's what we want (or if that was actually what was
>>>> intended.)
>>>>
>>>> I think it would be better to say:
>>>>
>>>> o The chain encoded MAY be incomplete; it is usually not
>>>>   necessary to include the self-signed certificate specifying
>>>>   the root authority.
>>>>
>>>>   It is NOT REQUIRED to specify any certificates other than
>>>>   the senders certificate.  If the verifier has a trust anchor
>>>>   that is not the self signed root, these other certificates may
>>>>   not be needed.  However, omitting certificates from the chain
>>>>   may make it more likely that certificate verification will fail
>>>>   because the verifier is not able to build a chain to a trusted
>>>>   anchor.
>>>>
>>>> I'm worried in particular that there might be cases where 
>> the signer 
>>>> doesn't have all the certificates necessary to chain to the root 
>>>> easily available.  (I'm not sure if this is a real life 
>> use case or 
>>>> not.)
>>>>
>>>> If we do decide we want to REQUIRE all the certificates, I 
>> think we 
>>>> should change the paragraph referenced to make that clear:
>>>>
>>>> o The self-signed certificate specifying the root authority MEY be
>>>>   omitted.  All other certificates in the chain up to the root
>>>>   authority MUST be included.
>>>>
>>>> Also, is there any correlation between certificates and OSCP 
>>>> responses?  Currently, there is nothing that constrains the OCSP 
>>>> responses included to have anything to do with the certificate.
>>>>
>>>> Is there a need for more than one OCSP response per issuer?
>>>> Would it make more sense to do:
>>>>
>>>>         uint32    certificate-count
>>>>           string    certificate
>>>>           string    ocsp-response-from-certificate-issuer
>>>> 	  [1..certificate-count]
>>>>
>>>> Use a 0 length string if no OCSP response is available.
>>>>
>>>> I'm not sure whether this is a good idea or if I'm just showing my 
>>>> ignorance.
>>>>
>>>> Thanks,
>>>>
>>>> Joseph
>>>>
>>>>
>>
>>




Home | Main Index | Thread Index | Old Index