Subject: RE: Comments on draft-ietf-pkix-cert-utf8-01.txt

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Mar 2006 10:14:41 -0800

I would think the language for encoding subject alternative names should
be included since the name constraints are enforced on them also.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Russ Housley
Sent: Wednesday, March 01, 2006 10:36 AM
To: Jim Schaad; [email-masked]
Subject: Re: Comments on draft-ietf-pkix-cert-utf8-01.txt

Jim:

Thanks for the first WG Last Call comments.

>1.  Page 2 last paragraph:  "issuer and and the old" - remove duplicate
>"and"

Agree.  It will be included in the next revision.

>2.  Inclusion of the section title would improve the readablity of the
>document.

Agree.  It will be included in the next revision.

>3.  Text dealing with connocalization (or the non-requirement for)
should be
>included in the document.

Why?  That part of the text is unchanged.  This document cannot be 
understood without the rest of RFC 3280.

>4.  Does any text regarding Subject and issuer Alt Names need to be
>included?

Good question.  I asked this question when I read Santosh's posting, 
but no one has responded.  My initial reaction is that we should add 
it, but I would like to hear what others think.

Russ

---

From: "Santosh Chokhani" <[email-masked]>
Date: Wed, 1 Mar 2006 12:20:08 -0800

Stefan,

What about when the subject alternative name is DN

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
On Behalf Of Stefan Santesson
Sent: Wednesday, March 01, 2006 12:35 PM
To: Russ Housley; Jim Schaad; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-cert-utf8-01.txt

On last issue, Subject and Issuer Alt Names I suggest we stay silent.

This draft is only concerned with fixing the false/bad utf-8 requirement
from RFC 3280. That text in rfc 3280 did not cover alt names so it
doesn't need fixing.

The only alt name that has directoryString encoding is EDI Party name
which is totally non relevant from a chaining and name constraints
perspective.

OtherName names should/could have their own conventions defined that we
don't want to mess with.

If something needs be said anyway, I suggest we do that in rfc 3280bis.
Better to keep this small draft focused.

Stefan Santesson
Program Manager, Standards Liaison
Windows Security

-----Original Message-----
Sent: den 1 mars 2006 16:36

Jim:

should be

Russ

---

From: "Stefan Santesson" <[email-masked]>
Date: Fri, 3 Mar 2006 07:22:44 -0000

Jim,

Of course, I missed that we did a change on that in 3280bis.

The section in 3280:

   When the subjectAltName extension contains a DN in the directoryName,
   the DN MUST be unique for each subject entity certified by the one CA
   as defined by the issuer name field.  A CA MAY issue more than one
   certificate with the same DN to the same subject entity.

Should be changed into the text of 3280bis

   When the subjectAltName extension contains a DN in the directoryName,
   the encoding rules are the same as those specified for the issuer
   field in section 4.1.2.4.  The DN MUST be unique for each subject
   entity certified by the one CA as defined by the issuer name field.
   A CA MAY issue more than one certificate with the same DN to the same
   subject entity.

Stefan Santesson

-----Original Message-----
From: Jim Schaad [mailto:[email-masked]] 
Sent: den 3 mars 2006 04:04
To: Stefan Santesson; 'Russ Housley'; [email-masked]
Subject: RE: Comments on draft-ietf-pkix-cert-utf8-01.txt

Stefan,

I was looking at the directoryName which uses a Name type and would be
filled in for the cases wher the subject DN is not used.

Jim

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Stefan Santesson
> Sent: Thursday, March 02, 2006 8:31 PM
> To: Santosh Chokhani; Russ Housley; Jim Schaad; [email-masked]
> What alternative name form do you think needs this guidance?
> 
> As I said, only EDIParyName make use of directoryString and 
> we don't define name constraints matching rules for that name anyway.
> 
> If this draft is to serve its purpose, it should only fix the 
> error from rfc3280. This goes beyond that.
> 
> 
> Stefan Santesson
> On Behalf Of Santosh Chokhani
> Sent: den 1 mars 2006 19:15
> I would think the language for encoding subject alternative 
> names should be included since the name constraints are 
> enforced on them also.
> 
> Why?  That part of the text is unchanged.  This document 
> cannot be understood without the rest of RFC 3280.
> 
> Good question.  I asked this question when I read Santosh's 
> posting, but no one has responded.  My initial reaction is 
> that we should add it, but I would like to hear what others think.
> 
> Russ
> 
> 
> 
> 
>