Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt

From: "David A. Cooper" <[email-masked]>
Date: Wed, 05 Jul 2006 11:50:09 -0400

Sean,

common in-line

Turner, Sean P. wrote:

David comments in-line. I snipped out the ones that you accepted or you
resolved.
------------------

4. Sec 4 1st para last sentence: remove required to support a PKI. All

of the internet defined extensions are optional so they can't be
required to support a PKI for the internet community.

The full sentence is "This section also defines private
extensions required to support a PKI for the Internet
community." These extensions (authorityInfoAccess an
subjectInfoAccess) are needed even though it is not necessary
to include them in all certificates.

Exactly - they are needed but not required. I still think the sentence ought
to read: This section also defines extension to support the PKI for the
internet community. There's no need to say required.

I looked at the earlier RFCs and discovered that this sentence has
appeared in the PKIX certificate and CRL profile, unchanged, since RFC
2459.  Barring evidence to the contrary, I think that indicates rough
consensus in favor of the current text.

6. Sec 4.2.1.2: Can we suggest using something other than SHA-1 for key

id generation? How about striking SHA-1 from the methods and adding the

new sentence to both: The hash algorithm employed can be the same
algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256, SHA-384).

Section 4.2.1.2 simply states that the two methods described
are two common methods for generating key identifiers. The
text explicitly does not restrict CAs to using these methods.

This one didn't come across very well. I know there's no security issue and
there are just examples but sometimes people just implement the examples and
we end up getting stuck with those. Further I'm trying to avoid silly things
like somebody saying I won't use a spec that has SHA1 and they don't
understand that they're only examples.

It is also not clear why one would want to use SHA-256, SHA-384, etc.
instead of SHA-1. There are no security issues associated
with key identifiers, so it would seem that using a hash
algorithm with a longer output would just make the
certificates larger.

I wasn't clear with the use any hash algorithm part. I think the example
should still indicate that a 160bit output is used with whatever hash
algorithm is used. So for logner hash outputs they only use 160bits of it.
It doesn't matter which bits as long as the CA is consistent.

These examples for methods of generating key identifiers also date back
to RFC 2459 and I still don't see the motivation for changing.

You say that even though they are just examples, "sometimes people just
implement the examples and we end up getting stuck with those."  Why is
that a problems is there is nothing wrong with the examples.

While it is hypothetically possible that someone may claim that they
refuse to use 3280bis since it mentions the use of SHA-1 somewhere, I
don't think we should change the document just to prevent the that
possibility.

7. Sec 4.2.1.6/4.1.2.6: The 2nd paragraph of 4.2.1.6 points out that
since the SAN is bound to the public key that the CA MUST verify the
each part of the SAN. I think a similar statement ought to be added to

the subject section (4.1.2.6) to indicate that "All parts of the
subject name MUST be verified by the CA as it is bound to the public key".

It is my understanding the the statement in 4.2.1.6 was added
because there were cases in which CAs were verifying the name
they included in the subject field but not names included in
the subjectAltName extension. Are you aware of a similar
problem with the subject field?

No. It was a motherhood and apple pie statement.

So, why does the statement need to be added?

13. Sec 5.2.5 8th para (one before the ASN.1): The sentence about the

onlyContainsAttributeCerts seems to hang. Recommend adding "In either case"

to the beginning of the sentence to address the case when either
onlyContainsUserCerts or onlyContainsCACerts is set to TRUE.
Additionally, recommend adding the following for completeness as a new

last paragraph: "If the scope of the CRL only includes attribute
certificates then the onlyContainsAttributeCerts MUST be set to TRUE
and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to FALSE."

This sentence was really meant to say that
onlyContainsAttributeCerts MUST be set to FALSE in all cases,
not just when either onlyContainsUserCerts or
onlyContainsCACerts is set to TRUE. In order to make this
more clear, the sentence about onlyContainsAttributeCerts has
been moved to the end of the paragraph and now reads:

Conforming CRLs issuers MUST set the
onlyContainsAttributeCerts boolean
to FALSE.

Are we not addressing the case when the CRL is only for attribute
certificates?

Correct.  This profile only address public key certificates.

In addition, the original definition of the issuingDistributionPoint
extension in X.509 did not include the onlyContainsAttributeCerts field
and the resolution to DR 305 resulted in X.509 reverting to the
original definition of the extension.  So, the X.509 definition of the
issuingDistributionPoint extension does not include the
onlyContainsAttributeCerts field.  Always setting this value to FALSE
ensures consistency with X.509.  (Note that the resolution to DR 305
defined a new CRL extension for defining the scope of a CRL with
respect to attribute certificates, but that extension does not belong
in 3280bis since 3280bis only deals with public key certificates.)

6. Sec 4.2.1.6 1st para: r These identities may be included in
addition to or in the place of the identity/These identities may be
included in addition to or in the place of, in the case of non-CAs, the

identity. The paragraph mixes SAN and IAN, but assumed the 2nd sentence addressed SAN.

Section 4.1.2.6 already very clearly states under what
circumstances a non-empty DN is required. I don't think that
information needs to be repeated here.

I'm only hoping to clarify the 1st paragraph. It's unclear whether the
"these" refers to SAN or IAN after a couple of reads of the 1st para since
IAN is thrown in later in the paragraph. If you add the ", in the case of
non-CAs," it's clear that the 2nd sentence refers to the SAN.

I don't see how "these" could be read as referring to the issuerAltName
extension.

Also, note that saying "in the case of non-CAs" would be misleading
since section 4.1.2.6 states that certificates issued to CRL issuers
must also include a non-empty subject DN.

17. Sec 4.2.1.6: Add the following to clarify that there is no
dependency in this spec between SAN and IAN: This specification places

no requirement on CAs, whose certificate includes Issuer Alterative
name, to include Subject Alternative names in certificates issued by the CA.

While this statement is certainly true, I don't understand
the need to include it in section 4.2.1.6. Is there any
reason that readers of 3280bis would believe that any
certificate that includes an issuerAltName extension would
also need to include a subjectAltName extension?

I'm only trying to protect against something silly like somebody who assumes
that the issuer/subject fields are in all PKCs then IAN/SAN ought to be in
all certificate too. An explicit indication that there is no requirement to
include one if the other is present removes any doubt.

As long as 3280bis is already, it would be much longer if we added
explicit statements to contradict every incorrect assumption that
anybody could imagine that someone might make.  Although, there have
certainly been cases where people have assumed that a certain
requirement exists and then have insisted that the requirement must
exist unless the document includes an explicit statement that the
requirement does not exist (even when there is nothing in the document
that even hints at the suggestion that such a requirement exists).

I think the best we can do is to try to ensure that the document does
not include statements that imply things that are incorrect.  Explicit
statements contradicting incorrect assumptions should only be used
where there is evidence that confusion exists in that area.  Adding
statement to deal with the hypothetical possibility that someone might
make an incorrect assumption about something, despite there being
nothing in the document that could lead to that assumption and no
evidence that people have been confused in that area, seems unnecessary.

Dave

---

From: "David A. Cooper" <[email-masked]>
Date: Wed, 05 Jul 2006 12:14:31 -0400

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: Stephen Farrell <[email-masked]>
Date: Wed, 05 Jul 2006 17:34:01 +0100

David A. Cooper wrote:

> What do others think?  

Its fine as-is IMO.

Stephen.

---

From: "Kemp David P." <[email-masked]>
Date: Wed, 5 Jul 2006 14:08:52 -0400

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,

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:

name form (from an potentially unbounded set of name forms) except these
three name forms.

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.
	 
	on the x400Address, ediPartyName, or registeredID name forms.
Period.  

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.

 
See above.

---

From: "Turner, Sean P." <[email-masked]>
Date: Thu, 6 Jul 2006 19:32:18 -0400

Dave,
 
#4 - While I don't think length of time in print is a good reason to not
accept a comment, I thought it was an editorial comment and as editor you're
free to dismiss/reject/overrule the comment ;)
#6 - Also thought this one was editorial. If the text doesn't add an error
or ambiguity, I don't see the harm in adding it though.
#7 - Also thought this one was editorial.  But upon another read, the bit in
the security considerations about the importance of the procedures to
validate the bindings addresses my concerns.
#13 - I think is fixed.
#16 - I also think this is editorial. But, if you won't change the 2nd
sentence will you delete the "(or issuer alternative name)" from the last
sentence in the 1st paragraph?
#17 - Also thought this one was editorial. With the fix to 4.2.1.7, my
concerns are addressed.
 
spt

  _____  

From: [email-masked] [mailto:[email-masked]] On
Behalf Of David A. Cooper
Sent: Wednesday, July 05, 2006 11:50 AM
To: Turner, Sean P.
Cc: pkix
Subject: Re: I-D ACTION:draft-ietf-pkix-rfc3280bis-03.txt

Sean,

common in-line

Turner, Sean P. wrote: 

resolved. 

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

      

I looked at the earlier RFCs and discovered that this sentence has appeared
in the PKIX certificate and CRL profile, unchanged, since RFC 2459.  Barring
evidence to the contrary, I think that indicates rough consensus in favor of
the current text.

algorithm paired with the signature algorithm (e.g., SHA-1, SHA-256,
SHA-384).

certificates larger.

These examples for methods of generating key identifiers also date back to
RFC 2459 and I still don't see the motivation for changing.

You say that even though they are just examples, "sometimes people just
implement the examples and we end up getting stuck with those."  Why is that
a problems is there is nothing wrong with the examples.

While it is hypothetically possible that someone may claim that they refuse
to use 3280bis since it mentions the use of SHA-1 somewhere, I don't think
we should change the document just to prevent the that possibility.

and both onlyContainsUserCerts and onlyContainsCACerts MUST be set to
FALSE."

      

      to FALSE.

certificates?

In addition, the original definition of the issuingDistributionPoint
extension in X.509 did not include the onlyContainsAttributeCerts field and
the resolution to DR 305 resulted in X.509 reverting to the original
definition of the extension.  So, the X.509 definition of the
issuingDistributionPoint extension does not include the
onlyContainsAttributeCerts field.  Always setting this value to FALSE
ensures consistency with X.509.  (Note that the resolution to DR 305 defined
a new CRL extension for defining the scope of a CRL with respect to
attribute certificates, but that extension does not belong in 3280bis since
3280bis only deals with public key certificates.)

identity.  The paragraph mixes SAN and IAN, but assumed the 2nd sentence
addressed SAN.

      

Also, note that saying "in the case of non-CAs" would be misleading since
section 4.1.2.6 states that certificates issued to CRL issuers must also
include a non-empty subject DN.

      

As long as 3280bis is already, it would be much longer if we added explicit
statements to contradict every incorrect assumption that anybody could
imagine that someone might make.  Although, there have certainly been cases
where people have assumed that a certain requirement exists and then have
insisted that the requirement must exist unless the document includes an
explicit statement that the requirement does not exist (even when there is
nothing in the document that even hints at the suggestion that such a
requirement exists).

I think the best we can do is to try to ensure that the document does not
include statements that imply things that are incorrect.  Explicit
statements contradicting incorrect assumptions should only be used where
there is evidence that confusion exists in that area.  Adding statement to
deal with the hypothetical possibility that someone might make an incorrect
assumption about something, despite there being nothing in the document that
could lead to that assumption and no evidence that people have been confused
in that area, seems unnecessary.

Dave