Subject: Re: [Gen-art] Gen-ART review of draft-ietf-hip-cert-09

From: Samu Varjonen <[email-masked]>
Date: Wed, 02 Mar 2011 10:53:34 +0200

On 24/02/11 13:11, Samu Varjonen wrote:
> On 16/02/11 17:16, Vijay K. Gurbani wrote:
>> I am the assigned Gen-ART reviewer for this draft. For background on
>> Gen-ART, please see the FAQ at
>> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
>>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-hip-cert-09
>> Reviewer: Vijay K. Gurbani
>> Review Date: Feb-16-2011
>> IETF LC End Date: Mar-01-2011
>> IESG Telechat date: Mar-03-2011
>>
>> Summary: 1 major issue. Besides that, the draft is ready as an
>> Experimental.
>>
>> Major issues: 1
>> Minor issues: 0
>> Nits: 1
>>
>> Major issue:
>>
>> - Has this draft been vetted through pkix? I am curious: what
>> happens if both the CN and SAN are present? Which one takes
>> precedence? In your Appendix B, you show the CN and SAN as both
>> being the same, but what happens if they are different? You may
>> want to check with the pkix WG folks to make sure that the your
>> use of identities in CN and SAN are okay.

CN and SAN should not be different. The SAN is the primary way of incorporating 
the HITs into the certificates. The CN part is a reminder for the developer that 
the DN cannot be empty and as a last resort you can put the HIT into the CN. IMO 
it should be clearly written into the document that when CN is used it must be 
the same HIT as the SAN.

>>
>> Nits:
>>
>> - S3:
>> s/or the subject the respective HIT/or the subject, the respective HIT/
>

OK

> Thanks for the comments. I will look into these as soon as possible and will
> give an answer to them on this chain.

Sorry, for the delay.

BR,
Samu Varjonen

> BR,
> Samu Varjonen
>> Thanks,
>> - vijay

---

From: Samu Varjonen <[email-masked]>
Date: Wed, 02 Mar 2011 14:46:23 +0200

> it should be clearly written into the document that when CN is used it must be

Here is the edited paragraph

    When using X.509.v3 certificates to transmit information related to
    HIP hosts, HITs MAY be enclosed within the certificates.  HITs can
    represent an issuer, a subject, or both.  In X.509.v3 HITs are
    represented as issuer or subject alternative name extensions as
    defined in [RFC5280].  It is REQUIRED to use the Fully Qualified
    Domain Name (FQDN) [RFC1035] / Network Access Identifier (NAI)
    [RFC4282], if one exists, from the hosts HOST_ID parameter in the DN.
    If only the HIT of the host is presented as either the issuer or the
    subject the respective HIT, from the issuer or the subject
    alternative name extension, 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.  The full HIs
    are presented in the public key entries of X.509.v3 certificates.

---

From: Russ Housley <[email-masked]>
Date: Wed, 2 Mar 2011 16:38:23 -0500

Samu:

> CN and SAN should not be different. The SAN is the primary way of incorporating the HITs into the certificates. The CN part is a reminder for the developer that the DN cannot be empty and as a last resort you can put the HIT into the CN. IMO it should be clearly written into the document that when CN is used it must be the same HIT as the SAN.

Actually, RFC 5280 does allow an empty subject name if the SubjectAltName extension is critical.

Was the PKIX WG asked to review this document?

Russ

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 02 Mar 2011 16:49:42 -0600

On 03/02/2011 06:46 AM, Samu Varjonen wrote:
[...]
> are presented in the public key entries of X.509.v3 certificates.

Samu: I am sorry, but the above is confusing and I am unable to
parse it completely.

The basic question in my original email remains.

I had a quick side conversation with the pkix chairs to ask their
view on how to proceed, and am afraid they have more questions
than answers.

I think the best thing to do may be to have a quick review with
pkix.  Please realize that I am not delaying the publication of your
draft, nor hindering it.  But having worked with X.509 certificates
before, I am painfully aware that unless we spell out unambiguously
what the behaviour should be, implementations will vary in their
interpretation.  This will not help your draft in the long run
(even though I realize that the draft is targeted as an Experimental
RFC and not a standards-track).

The pkix WG chairs are peripherally aware of the draft through my
communication (especially Stefan Santesson), so if you open up a channel
to them I am sure that they will guide you much better.  Stefan also
had good comments that I will pass on to you in a separate email.

Thanks,

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