Subject: RE: name constraints on x400Address, ediPartyName, and registered ID name forms

From: Sharon Boeyen <[email-masked]>
Date: Thu, 6 Jul 2006 11:06:37 -0400

I agree with softening the statement to should not because of the argument
David makes. If we allow name constraints for "otherName" name forms it
seems excessive to forbid these completely. That can lead to confusion for
systems that actually need to support such name constraints in a particular
environment (I've seen name constraints on X.400 addresses for example,
although they could be deemed outside the scope of "the Internet PKI"). 
 
Cheers,
Sharon

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Kemp David P.
Sent: Wednesday, July 05, 2006 2:09 PM
To: David A. Cooper; Turner, Sean P.
Cc: pkix
Subject: RE: name constraints on x400Address, ediPartyName, and registeredID
name forms

MUST NOT seems excessive, given that interoperability is not guaranteed for
rfc822Name, etc, that applications are not required to support.

But since the express purpose of a profile is to foster interoperability, it
seems reasonable for 3280bis to discourage the use of name constraints for
some name forms including those defined using otherName:

"Conforming CAs MUST mark this extension as critical and SHOULD NOT impose
name constraints on the x400Address, ediPartyName, registeredID, or
otherName name forms."

As an aside, I'm not sure why registeredID made it onto the list of
forbidden name constraint forms; OIDs are purely hierarchical and constraint
processing for this name form would be particularly simple to implement.
But if there is little demand for names of this form there is little harm in
discouraging its use.  There would be harm in continuing to forbid it.

Dave K

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Wednesday, July 05, 2006 12:15 PM
To: Turner, Sean P.
Cc: pkix
Subject: name constraints on x400Address, ediPartyName, and registeredID
name forms

Sean,

If I understand you correctly now, your concern is not that 3280bis seems
contradictory, but that you disagree with 3280bis forbidding conforming CAs
from imposing name constraints on the x400Address, ediPartyName, and
registeredID name forms.  I can't remember why this requirement was included
in the initial draft of 3280bis, but I can see that there is a good argument
for removing it.

While it is a good idea to limit the set of name forms for which name
constraints are imposed in order to maximize interoperability, this does not
do that.  3280bis currently states:

      Applications conforming to this profile MUST be able to process name
      constraints that are imposed on the directoryName name form and
      SHOULD be able to process name constraints that are imposed on the
      rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
      forms.

If the goal was to maximize interoperability, then 3280bis should have
forbidden imposing name constraints on any name forms except those mentioned
above.  However, while 3280bis forbids specifying name constraints for the
x400Address, ediPartyName, and registeredID name forms, it does not forbid
specifying name constraints for names forms that are defined for inclusion
within otherName.  So the effect is that 3280bis permits specifying permits
specifying name constraints for any name form (from an potentially unbounded
set of name forms) except these three name forms.

What do others think?  Is there is any reason to forbid conforming CAs from
specifying name constraints for these three name forms while not forbidding
conforming CAs from specifying name constraints for any name form that might
be defined for inclusion within otherName?

Dave

Turner, Sean P. wrote:

8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
constraints on ediPartyName or registeredID but the 14th para (the one 

before the ASN.1) indicates that ediPartyName and registeredId are not 

defined in this spec but MAY be defined in another spec. Sounds to me 

like it would be hard to convince a customer that you could write a 
name constraints that can ever be 3280bis compliant since whatever you 

wrote MUST NOT be imposed/implemented. It's not clear that the name 
constraints shouldn't be imposed because they're not defined in the 
spec or whether they should never ever be imposed.

3280bis states:
 
      The syntax and semantics for name constraints for otherName,
      ediPartyName, and registeredID are not defined by this specification,
      however syntax and semantics for name constraints for other name
      forms may be specified in other documents.
 
A CA conforming to 3280bis MUST NOT impose name constraints 
on the x400Address, ediPartyName, or registeredID name forms.  Period.  
However, just as [SRVSAN] specifies the syntax and semantics 
for name constraints on the SRVName name form, other 
documents could specify the syntax and semantics for name 
constraints on other name forms.  Given that 3280bis forbids 
conforming CAs from imposing name constraints on the 
x400Address, ediPartyName, or registeredID name forms, it 
would seem to be inappropriate for another PKIX (or even 
IETF) document to specify syntax and semantics for name 
constraints on ediPartyName or registeredID name forms, but 
3280bis is just one profile of X.509.  A different profile of 
X.509 may permit the specification of name constraints on 
these name forms and may specify the syntax and semantics for 
imposing constraints on those name forms.  While 3280bis 
states that conforming CAs MUST NOT impose name constraints 
on these name forms, conforming relying parties are permitted 
to implement the ability to process name constraints on these 
name forms since conforming relying parties are not 
restricted to only accepting certificates that are issued in 
conformance with 3280bis.

I don't understand why these name forms were specifically picked out. For
x400Address I assume it's that nobody cares, but you could easily write a
rule that said the OR Address attributes (just like DNs) must be within the
ones included. I write the rules if we decide we need them. For registeredId
I get that it's an OID so there's structure to it so it's imposible to write
rules but why couldn't somebody decide to carve up an OID tree and say
something like make sure the 1st 6 components of the OID are present in all
names. For the ediPartyName you could say the nameAssigner must be present
in all PKCs.
 
If there is no way I can say with a straight face that a CA that requires a
name constraints for x400Address, ediPartyName, or registeredID is
compliant, I've got a problem with this what it says because being compliant
with RFC3280 is the gold standard; besides I think the rules are easy enough
to write I don't understand why these particular name forms were omitted
(there may be good reasons I'm unaware of).

9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name 
constraints on x400Address name forms but the last sentence in the 10th 

para last says X400Address MUST be applied to x.400 addresses. See #8.

While a conforming CA MUST not impose name constraints on the 
x400Address name form, a conforming relying party MAY 
implement the ability to process  such constraints.  As with 
any other name form, if a certificate includes name 
constraint on the x400Address name form and a subsequent 
certificate in the certification path includes a 
subjectAltName extension with an x400Address name, the 
relying party MUST either process the constraint or reject 
the certification path.

See above.

---

From: "Michael Myers" <[email-masked]>
Date: Thu, 6 Jul 2006 17:41:55 -0800

MessageSharon, Dave:

Negative requirements cannot be tested.

Mike
  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On
Behalf Of Sharon Boeyen
  Sent: Thursday, July 06, 2006 7:07 AM
  To: 'Kemp David P.'; David A. Cooper; Turner, Sean P.
  Cc: pkix
  Subject: RE: name constraints on x400Address, ediPartyName, and
registeredID name forms

  Cheers,
  Sharon
    -----Original Message-----
    From: [email-masked] [mailto:[email-masked]]
On Behalf Of Kemp David P.
    Sent: Wednesday, July 05, 2006 2:09 PM
    To: David A. Cooper; Turner, Sean P.
    Cc: pkix
    Subject: RE: name constraints on x400Address, ediPartyName, and
registeredID name forms

    MUST NOT seems excessive, given that interoperability is not guaranteed
for rfc822Name, etc, that applications are not required to support.

    But since the express purpose of a profile is to foster
interoperability, it seems reasonable for 3280bis to discourage the use of
name constraints for some name forms including those defined using
otherName:

    "Conforming CAs MUST mark this extension as critical and SHOULD NOT
impose name constraints on the x400Address, ediPartyName, registeredID, or
otherName name forms."

    Dave K

----------------------------------------------------------------------------

    From: [email-masked] [mailto:[email-masked]]
On Behalf Of David A. Cooper
    Sent: Wednesday, July 05, 2006 12:15 PM
    To: Turner, Sean P.
    Cc: pkix
    Subject: name constraints on x400Address, ediPartyName, and registeredID
name forms

    Sean,

    If I understand you correctly now, your concern is not that 3280bis
seems contradictory, but that you disagree with 3280bis forbidding
conforming CAs from imposing name constraints on the x400Address,
ediPartyName, and registeredID name forms.  I can't remember why this
requirement was included in the initial draft of 3280bis, but I can see that
there is a good argument for removing it.

          Applications conforming to this profile MUST be able to process
name
          constraints that are imposed on the directoryName name form and
          SHOULD be able to process name constraints that are imposed on the
          rfc822Name, uniformResourceIdentifier, dNSName, and iPAddress name
          forms.

    What do others think?  Is there is any reason to forbid conforming CAs
from specifying name constraints for these three name forms while not
forbidding conforming CAs from specifying name constraints for any name form
that might be defined for inclusion within otherName?

    Dave

    Turner, Sean P. wrote:

8. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose name
constraints on ediPartyName or registeredID but the 14th para (the one
before the ASN.1) indicates that ediPartyName and registeredId are not
defined in this spec but MAY be defined in another spec. Sounds to me
like it would be hard to convince a customer that you could write a name
constraints that can ever be 3280bis compliant since whatever you
wrote MUST NOT be imposed/implemented. It's not clear that the name
constraints shouldn't be imposed because they're not defined in the spec or
whether they should never ever be imposed.      3280bis states:       The
syntax and semantics for name constraints for otherName,      ediPartyName,
and registeredID are not defined by this specification,      however syntax
and semantics for name constraints for other name      forms may be
specified in other documents. A CA conforming to 3280bis MUST NOT impose
name constraints on the x400Address, ediPartyName, or registeredID name
forms.  Period.  However, just as [SRVSAN] specifies the syntax and
semantics for name constraints on the SRVName name form, other documents
could specify the syntax and semantics for name constraints on other name
forms.  Given that 3280bis forbids conforming CAs from imposing name
constraints on the x400Address, ediPartyName, or registeredID name forms, it
would seem to be inappropriate for another PKIX (or even IETF) document to
specify syntax and semantics for name constraints on ediPartyName or
registeredID name forms, but 3280bis is just one profile of X.509.  A
different profile of X.509 may permit the specification of name constraints
on these name forms and may specify the syntax and semantics for imposing
constraints on those name forms.  While 3280bis states that conforming CAs
MUST NOT impose name constraints on these name forms, conforming relying
parties are permitted to implement the ability to process name constra
 ints on these name forms since conforming relying parties are not
restricted to only accepting certificates that are issued in conformance
with 3280bis.     I don't understand why these name forms were specifically
picked out. Forx400Address I assume it's that nobody cares, but you could
easily write arule that said the OR Address attributes (just like DNs) must
be within theones included. I write the rules if we decide we need them. For
registeredIdI get that it's an OID so there's structure to it so it's
imposible to writerules but why couldn't somebody decide to carve up an OID
tree and saysomething like ma
 ke sure the 1st 6 components of the OID are present in allnames. For the
ediPartyName you could say the nameAssigner must be presentin all PKCs. If
there is no way I can say with a straight face that a CA that requires aname
constraints for x400Address, ediPartyName, or registeredID iscompliant, I've
got a problem with thi
 s what it says because being compliantwith RFC3280 is the gold standard;
besides I think the rules are easy enoughto write I don't understand why
these particular name forms were omitted(there may be good reasons I'm
unaware of).   9. Sec 4.2.1.10: 3rd para indicates that CAs MUST NOT impose
name constraints on x400Address name forms but the last sentence in the 10th
para last says X400Address MUST be applied to x.400 addresses. See #8.
While a conforming CA MUST not impose name constraints on the x400Address
name form, a conforming relying party MAY implement the ability to process
such constraints.  As with any other name form, if a certificate includes
name constraint on the x400Address name form and a subsequent certificate in
the certification path includes a subjectAltName extension with an
x400Address name, the relying party MUST either process the constraint or
reject the certification path.
     See above.