Subject: [pkix] PKIX review on draft-ietf-hip-cert-09

From: Stefan Santesson <[email-masked]>
Date: Thu, 03 Mar 2011 17:15:16 +0100

PKIX has been asked by the IESG to review draft-ietf-hip-cert-09,
currently on the IESG agenda.

http://tools.ietf.org/html/draft-ietf-hip-cert-09

The GenArt reviewer spotted some issues. My comments are provided below.
Please share your view on the subject.

/Stefan

On 11-03-02 5:36 PM, "Stefan Santesson" <[email-masked]> wrote:

>The question here is how you define what is different.
>
>On your direct question:
>For subject information to be different in the subject field and the SAN
>to be different, their definition must be within a scope that allows them
>to be compared. The problem is that I can't find any information in the
>certificate that would inform the certificate user that a value in the CN
>field carries the same information as in a SAN extension.
>
>One immediate comment is that the abbreviation "HIT" (Host Identity Tag)
>is not explained or written out once in the draft even though mentioned
>many times. I had to go to RFC 5201 to figure out what it means. Some
>text 
>in line with "Host Identity Tag (HIT) as defined in [RFC5201]" would be
>in 
>place in the document.
>
>
>Reading the draft under revision, I find the text confusing:
>
>   In X.509.v3 HITs are
>   represented as issuer or subject alternative name extensions as
>   defined in [RFC5280].
>
>This is factually incorrect as RFC 5280 do not discuss inclusion of HITs.
>What would be correct would be to say:
>
>   HITs are represented as an IPv6 address. IPv6 addresses representing
>   an issuer or a subject are stored in X.509 certificates using the
>   iPAddress GeneralName form
>   in the Subject Alternative Name extension and the Issuer Alternative
>   Name extension respectively
>   as defined in [RFC5280].
>
>
>
>The following is also confusing:
>
>   If only the HIT of the host is presented as
>   either the issuer or the subject the respective HIT MUST be placed
>   into the respective entity's DN's Common Name (CN) section in a colon
>   delimited presentation format defined in [RFC5952].  Inclusion of CN
>   is not necessary if DN contains any other naming information.
>
>
>
>After decoding this, I think they intended to say:
>
>   The Issuer and Subject field must contain a non empty DN. The
>commonName
>   attribute (CN) MAY contain the HIT of the respective subject or issuer
>   host using a colon delimited presentation format defined in [RFC5952].
>
>
>In the end my major concern is how the certificate user will know what
>information that is present in a CN and how that information is to be
>used 
>(It is clear that it may contain anything). If that information can be
>used in a manner that a relying party may treat it as a legitimate HIT,
>then I agree that the document ought to require the HIT in CN and the
>iPAddress General name to be consistent. The document should in such case
>further make sure that no CN value that is not intended to be a HIT, can
>be mistaken for a HIT.
>
>Finally I would question why the authors feel they have to store the HIT
>in a CN at all. I can somehow understand this as the issuer name as
>RFC5280 requires the Issuer DN to be non-empty. If the HIT is all you
>have, you have to place that in some form in the subject DN, and in such
>case the CN attribute could be reasonable. For subject names the DN may
>be 
>an empty sequence if the SAN extension is present and non-empty and is
>marked critical. I don't know enough about the specified protocol to
>determine if the storage of HIT in CN is legitimate or not.
>
>/Stefan
>
>
>
>
>On 11-03-02 3:32 PM, "Vijay K. Gurbani" <[email-masked]> wrote:
>
>>Stephen, Stefan: I am doing a Gen-ART review of
>>draft-ietf-hip-cert-09 [1].  This draft uses X.509 certificates
>>to impart host identity.  Relevant section to look at is
>>Section 3 of [1], first paragraph.
>>
>>The draft carries the subject identity in the Subject field
>>as well as the SAN field.  There is no guidance on what to do if
>>these identities are different (and I have raised this question
>>to the authors).  The authors have proposed that if there is
>>an identity in both the Subject and SAN, the identity must
>>be the same.
>>
>>RFC5280 states that:
>>
>>    If subject naming information is present only in the
>>    subjectAltName extension (e.g., a key bound only to an email
>>    address or URI), then the subject name MUST be an empty
>>    sequence and the subjectAltName extension MUST be critical.
>>
>>I just want to make sure that having similar identities in both
>>SAN and Subject is okay.
>>
>>Can you please let me know so I can close this issue.
>>
>>Thanks,
>>
>>[1] http://tools.ietf.org/html/draft-ietf-hip-cert-09
>>
>>- vijay
>>-- 
>>Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>>1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
>>Email: vkg@{bell-labs.com,acm.org} / [email-masked]
>>Web:   http://ect.bell-labs.com/who/vkg/