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

[Samu Varjonen <[e-mail]>]

On 23/09/10 16:37, Ari Keranen wrote:
> Hi,
>
> I had a quick look at this and here's some comments. Overall, I like the
> draft and hope to see it LC'd soon.
>
>
> 3. X.509.v3 Certificate Object and Host Identities
>
> 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.
>
> Could be more explicit on the presentation format, e.g. RECOMMEND (or
> MUST) RFC5952 canonical style.

OK.

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

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

>
> Some nits:
>
> Expand "HIP" in the title and abstract.
>

OK.

> The place of the "Requirements Language" section is a bit strange
> (compared to any other draft/RFC). Or is this some new formatting rule?
>

Looks a bit odd to me too. I'll check this out.

>
> 2. CERT Parameter
>
> Cert Type Describes the type of the certificate
>
> s/Describes/Indicates
>

OK.

>
> Hash and URL encodings (3 to 4) are used as defined in [RFC4306]
>
> s/to/and/
> since there are now only two instead of 4 options (and to be consistent
> with the others)
>

OK.

>
> 3. X.509.v3 Certificate Object and Host Identities
>
> In this scenario, it is recommended that the HIP peers have and use
>
> RFC2119-capitalize "recommended" (also later in the draft)
>

OK.

>
> 6. Error signaling
>
> If the Initiator does not send the certificate that the Responder
> requires the Responder may take actions (e.g. blocking the
> connection).
>
> "reject" instead of "blocking" might be more appropriate word here.
>

OK.

>
> 8. Security Considerations
>
> It is not recommended to use grouping or hash and URL encodings when
>
> RFC2119-capitalize "not recommended"
>

OK.

>
> Cheers,
> Ari
>
> On 09/23/2010 02:01 PM, Samu Varjonen wrote:
>> Hi,
>>
>> This is the updated version of the cert draft.
>>
>> Changes from version 03 to 04:
>>
>> o Added the non-HIP aware use case to the Section 3.
>>
>> o Clarified that the HITs are not always required in the
>> certificates.
>>
>> o Rewrote the signaling section.
>>
>> o LDAP URL to LDAP DN in Section 2 last paragraph.
>>
>> o CERT is always covered by a signature as it's type number requires
>>
>> o New example certificates
>>
>> o Style and language clean-ups
>>
>> o Changed IANA considerations
>>
>> o Revised the type numbers
>>
>> o RFC 2119 keywords
>>
>> o Updated the IANA considerations section
>>
>> o Rewrote the abstract
>>
>> Comments are appreciated.
>>
>> BR,
>> Samu
>>
>> On 09/23/2010 01:45 PM, [e-mail] wrote:
>>> A New Internet-Draft is available from the on-line Internet-Drafts
>>> directories.
>>> This draft is a work item of the Host Identity Protocol Working Group
>>> of the IETF.
>>>
>>>
>>> Title : HIP Certificates
>>> Author(s) : T. Heer, S. Varjonen
>>> Filename : draft-ietf-hip-cert-04.txt
>>> Pages : 13
>>> Date : 2010-09-23
>>>
>>> The CERT parameter is a container for X.509.v3 certificates and
>>> Simple Public Key Infrastructure (SPKI) certificates. It is used for
>>> carrying these certificates in HIP control packets. This document
>>> only specifies the certificate parameter and the error signaling in
>>> case of a failed verification. The use of certificates including how
>>> certificates are obtained, requested, and which actions are taken
>>> upon successful or failed verification are to be defined in the
>>> documents that use the certificate parameter. Additionally, this
>>> document specifies the representations of Host Identity Tags in
>>> X.509.v3 and SPKI certificates.
>>>
>>> A URL for this Internet-Draft is:
>>> http://www.ietf.org/internet-drafts/draft-ietf-hip-cert-04.txt
>>>
>>> Internet-Drafts are also available by anonymous FTP at:
>>> ftp://ftp.ietf.org/internet-drafts/
>>>
>>> Below is the data which will enable a MIME compliant mail reader
>>> implementation to automatically retrieve the ASCII version of the
>>> Internet-Draft.
>>>
>>>
>>>
>>> _______________________________________________
>>> Hipsec mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/hipsec
>>
>> _______________________________________________
>> Hipsec mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/hipsec
>