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

[Ari Keranen <[e-mail]>]

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.


        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?


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


Some nits:

Expand "HIP" in the title and abstract.

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


2. CERT Parameter

      Cert Type     Describes the type of the certificate

s/Describes/Indicates


    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)


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)


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.


8. Security Considerations

    It is not recommended to use grouping or hash and URL encodings when

RFC2119-capitalize "not recommended"


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