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

From: Samu Varjonen <[email-masked]>
Date: Mon, 04 Oct 2010 09:56:05 +0300

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.
>
>>>>
>>>> 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
>

---

From: Ari Keranen <[email-masked]>
Date: Tue, 05 Oct 2010 11:23:10 +0300

>> Any other suggestions/ideas?

We could be looking into a really corner case here (how often would one 
send more than one or two certificates?), but assuming this would 
happen, my point was that there will likely be no single certificate 
(chain) that fails, but rather all but one (or some) fail.

Also some certificates may fail for some registration (or other 
requested service) types and others for different types with a single 
HIP message. Hence, there could be a problem on how to match those with 
each other in the NOTIFY.

Anyhow, probably this problem is not that severe that we should add much 
complexity into the draft to solve this and having identifiers for (all) 
the failed certificates (i.e., those that were not accepted for any of 
the requested services) in the Notification data, as you suggested, is 
sufficient.

By the way, wouldn't Cert group and ID be sufficient information in the 
Notification data?

Cheers,
Ari

---

From: Samu Varjonen <[email-masked]>
Date: Thu, 07 Oct 2010 12:14:45 +0300

> the requested services) in the Notification data, as you suggested, is

OK

> By the way, wouldn't Cert group and ID be sufficient information in the

Yes, it would be, the count and type are not really necessary.