Re: [Hipsec] draft-ietf-hip-cert-04 review

[Samu Varjonen <[e-mail]>]

Hi,

Comments in-line...

On 10/04/2010 09:56 AM, Samu Varjonen wrote:
> Hi,
>
> Forgot to CC the list :)
>
> On 04/10/10 09:54, Samu Varjonen wrote:
>> On 29/09/10 16:51, Ari Keranen wrote:
>>> On 09/27/2010 01:01 PM, Samu Varjonen wrote:
>>>> On 23/09/10 16:37, Ari Keranen wrote:
>>>>> Format:
>>>>> Issuer: CN=hit-of-host
>>>>> Subject: CN=hit-of-host
>>>>>
>>>>> X509v3 extensions:
>>>>> X509v3 Issuer Alternative Name:
>>>>> IP Address:HIT-OF-HOST
>>>>> X509v3 Subject Alternative Name:
>>>>> IP Address:HIT-OF-HOST
>>>>>
>>>>> From here (and especially from the example) one gets the idea that the
>>>>> exact same information would be there 4 times. The issuer and subject
>>>>> can be (and often are?) different, right?
>>>>>
>>>>
>>>> The answer is above the example.
>>>>
>>>> "
>>>> If only HIP information is presented as either
>>>> the issuer or the subject the HIT is also placed into the respective
>>>> entity's DNs Common Name (CN) section in a colon delimited
>>>> presentation format. *Inclusion of CN is not necessary if DN contains
>>>> any other information.* It is RECOMMENDED to use the FQDN/NAI from
>>>> the hosts HOST_ID parameter in the DN if one exists.
>>>> "
>>>>
>>>> Do you think that this needs clarification?
>>>
>>> Yes, that would help.
>>>
>>> For example, what is meant by "only HIP information" is not really
>>> clear. Also I guess it should say "DN's" instead of "DNs" in the text.
>>> And there isn't any text on whether the issuer and subject HITs can be
>>> different (the text and example implies that they're always identical).
>>>
>>
>> OK, I can change the example to contain different HITs as issuer and
>> subject and clarify the paragraph.
>>

Here is the new version:

http://www.cs.helsinki.fi/u/sklvarjo/draft-ietf-hip-cert-04-pre04.txt

Can you check out especially Section 3. to see if the clarifications (for the 
above) work for you or if you have other suggestion for improving the document.

Thanks, Samu

>>>>>
>>>>> 6. Error signaling
>>>>>
>>>>> INVALID_CERTIFICATE 50
>>>>>
>>>>> Sent in response to a failed verification of a certificate.
>>>>> Notification Data contains 4 octets, in order Cert group,
>>>>> Cert count, Cert ID, and Cert type of the certificate
>>>>> parameter that caused the failure.
>>>>>
>>>>> How does the verifier determine which certificate (if there are more
>>>>> than one) caused the failure? Isn't it rather always so that none of
>>>>> the
>>>>> given certificates were valid (for this particular use)?
>>>>>
>>>>
>>>> In most cases I would say that one failed verification fails the
>>>> verification of the whole chain. But in a case where you send two
>>>> certificates/chains for different services and the other one fails you
>>>> might want to know which failed. Registration extensions the REG_FAILED
>>>> would reveal the failed chain. I would like to leave the possibility to
>>>> tell the specific failed certificate for HIP-aware applications. So,
>>>> maybe it should say that the Notification Data MAY contain 4 octets...
>>>
>>> OK. But what if you send three (or more) certificates?
>>
>> If I followed you correctly the Notification Data would need more than 4
>> octets to inform about more than one failed certificate in one or more
>> groups. How about "the Notification Data MAY contain n groups of 4
>> octets (n calculated from the length of the parameter) . The group
>> contains octets in the following order: Cert group, Cert count, Cert ID,
>> and Cert type."
>>
>> Any other suggestions/ideas?
>>
>>>
>>>
>>> Cheers,
>>> Ari
>>
>
> _______________________________________________
> Hipsec mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hipsec