Subject: [Hipsec] I-D Action:draft-ietf-hip-cert-04.txt

From: [email-masked]
Date: Thu, 23 Sep 2010 03:45:01 -0700 (PDT)

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.

---

From: Samu Varjonen <[email-masked]>
Date: Thu, 23 Sep 2010 14:01:17 +0300

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, [email-masked] wrote:
> _______________________________________________
> Hipsec mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/hipsec

---

From: Ari Keranen <[email-masked]>
Date: Thu, 23 Sep 2010 16:37:14 +0300

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

---

From: Samu Varjonen <[email-masked]>
Date: Mon, 27 Sep 2010 13:01:18 +0300

> MUST) RFC5952 canonical style.

OK.

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

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

> Expand "HIP" in the title and abstract.

OK.

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

> Cert Type Describes the type of the certificate

OK.

> since there are now only two instead of 4 options (and to be consistent

OK.

> RFC2119-capitalize "recommended" (also later in the draft)

OK.

> "reject" instead of "blocking" might be more appropriate word here.

OK.

> RFC2119-capitalize "not recommended"

OK.

---

From: René Hummen <[email-masked]>
Date: Wed, 29 Sep 2010 13:45:12 +0200

Hi,

below are some questions and ideas that crossed my mind while reading the cert draft in section "2. CERT Parameter":

1.) The CERT parameter ordering is not completely clear to me. In a scenario with only one certificate per group the CERT parameters should be placed in ascending order according to the Cert group. However, when a Cert group consists of multiple Cert parameters, how should the CERT parameters of the group be ordered? In my opinion, CERT parameters of the same Cert group must also be placed in ascending order according to their Cert ID, but that's not what "The numbers in the Cert ID field MUST start from 1 up to Cert count." implies. Additionally it is not stated where you start numbering certificates in a chain: at the root (i.e. root-CA) or at leaf (i.e. Host ID)?

2.) When spanning a certificate chain across multiple packets, adding the first certificates of a group _and_ an additional list of issuers for the remaining certificates might be beneficial. The issuer list allows a verifier to validate that it trusts one of the issuing parties of the chain. If none is trusted, the verifier signals an error and drops the current and subsequent packets. Otherwise, it compares the issuer of subsequently received certificates with the ones in the list and only proceeds with the verification of the chain if the comparison was successful. This way, a verifier does not have to store/verify certificates in case there exists no trust root for the chain. Of course, a sender can still lie about the issuers, but this will be evident from the relative cheap list comparison.

3.) And finally: what is the reason behind limiting the group count to 1 in case of a certificate chain spanning multiple packets?

BR,
René

--
Dipl.-Inform. Rene Hummen, Ph.D. Student
Chair of Communication and Distributed Systems
RWTH Aachen University, Germany
tel: +49 241 80 20772
web: http://ds.rwth-aachen.de/members/hummen

---

From: Ari Keranen <[email-masked]>
Date: Wed, 29 Sep 2010 16:51:01 +0300

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

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

Cheers,
Ari