Subject: RE: SubjectAltName verification

From: Peter Williams <[email-masked]>
Date: Wed, 24 May 2000 19:46:20 -0700

Steve:

Perhaps comment.

(1) You should realize that the text I quoted, repeated below from your
reply, is from RFC 2459.

(2) The text quoted is not some bullshit from Peter's English pen.

	(2.1) The text is the work of Ford et al., NIST/NSA, PKIX WG, 
		PKIX mailing list, IESG et al., and a PKIX WG and IETF Final
call.  

	(2.2) The text has been present in the I-Ds leading to RFC 2459 from
		very early moments of our mailing-list deliberations.

(3) You do not agree that the cited paragraph (from RFC 2459) represents
group consensus. That the same paragraph remains in son-of-2459 I-D is not 
relevant to you, presumably.

(4) You view the "supplement/replace" assumption stated by the authors
of RFC 2459, as stated in the 1st quoted sentence (from RFC 2459),
to be "out of the question". 

(5) You view the second sentence of the same quote (from RFC 2459) as 
"confusing."

(6) And...despite your repeated misdirections as chair, you will perhaps 
now agree that Peter did not write a word of the cited text that you
criticise so severely. THIS WG wrote and reviewed the text... 

(7) The text, which was discussed in mailing list discussions, also
passed Final Call in both PKIX WG and IETF Final Call.  

(8) IETF Final call is a conventional signal of consensus. But perhaps
not in PKIX WG, under the rules of our chairs.

(9) The use of quote symbols around text is an accepted practice to 
denote a quotation.

(10) The appendage of [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt] after
a quoted passage represents an accepted practice to clearly identify the
source of a quotation.

Peter.

-----Original Message-----
From: Stephen Kent [mailto:[email-masked]]
Sent: Wednesday, May 24, 2000 8:42 AM
To: Peter Williams
Cc: [email-masked]
Subject: RE: SubjectAltName verification

Peter,

>    "Some communities will need to supplement, or possibly replace, this
>    profile in order to meet the requirements of specialized application
>    domains or environments with additional authorization, assurance, or
>    operational requirements.  However, for basic applications, common
>    representations of frequently used attributes are defined so that
>    application developers can obtain necessary information without
>    regard to the issuer of a particular certificate or certificate revo-
>    cation list (CRL)." [RFC 2459, http://www.ietf.org/rfc/rfc2459.txt]
>
>Do you affirm the above to be group consensus?

No, I do not agree.

It seems out of place to insert text into a standard saying that "we 
understand if you don't want to use this standard."  So the first 
sentence is out of the question.

The second sentence confuses me.  What do you mean by "common 
representations of frequently used attributes?"  The "representation" 
of an attribute is its syntax, which is certainly part of the 
standard, but not the focus of this discussion.

Steve

---

From: Paul Koning <[email-masked]>
Date: Thu, 25 May 2000 10:13:48 -0400 (EDT)

>>>>> "Peter" == Peter Williams <[email-masked]> writes:

 Peter> Steve:

 Peter> Perhaps comment.

 Peter> (1) You should realize that the text I quoted, repeated below
 Peter> from your reply, is from RFC 2459. ...

 Peter> (6) And...despite your repeated misdirections as chair, you
 Peter> will perhaps now agree that Peter did not write a word of the
 Peter> cited text that you criticise so severely. THIS WG wrote and
 Peter> reviewed the text...

 >> "Some communities will need to supplement, or possibly replace,
 >> this profile in order to meet the requirements of specialized
 >> application domains or environments with additional authorization,
 >> assurance, or operational requirements.  However, for basic
 >> applications, common representations of frequently used attributes
 >> are defined so that application developers can obtain necessary
 >> information without regard to the issuer of a particular
 >> certificate or certificate revo- cation list (CRL)." [RFC 2459,
 >> http://www.ietf.org/rfc/rfc2459.txt]

That's all very nice, but I don't see any reason to disagree with
Steve's basic objection -- which is that it doesn't make much sense in
a standard to say "of course implementations are free not to conform
to the standard".  That's true, obvious, and irrelevant.  I wonder why
that text ever made it into this RFC.

     paul

---

From: Stephen Kent <[email-masked]>
Date: Thu, 25 May 2000 11:14:10 -0400

Peter,

>Perhaps comment.

I'll respond to each point.

>(1) You should realize that the text I quoted, repeated below from your

Whoops, caught me on that one :-).

>(2) The text quoted is not some bullshit from Peter's English pen.

Didn't say it was.

>		PKIX mailing list, IESG et al., and a PKIX WG and IETF Final

Guess I missed it the last time.  And, the fact that I missed it 
probably says something about the level of scrutiny that one ought to 
assume despite the list you cite here.  I know that the IESG members, 
other than the cognizant area director(s), do not, as a rule, read 
documents before approving them as RFCs.  And, given the large number 
of WGs that each AD must cover, they often rely primarily on WG 
chairs and the WG process to ensure that the documents are 
reasonable. So, it would be erroneous to assume that the review 
process ensures that all the cited parties have read an RFC carefully 
prior to its publication.

>		very early moments of our mailing-list deliberations.

I'll grant that it has probably been there for a long while.

>relevant to you, presumably.

The fact that it currently is in the revised text is relevant to me, 
and I'll see if we can fix that now that you have pointed it out. 
(See the end of this message.)

>to be "out of the question".

Yes, in my opinion, and in the opinion of at least one other WG 
member who cared to respond to your message. I'll ask Tim if he 
recalls where it came from. But the point is that it is an odd 
comment that seems out of place in a standards document of this sort. 
The fact that it was present and that I didn't notice it is a failure 
on my part, but that doesn't mean we can't fix it now.  Many 
reviewers, myself included, probably focused on the technical details 
of 2459, e.g., syntax and processing rules, rather than this 
context-setting text.

X.509 and other standards have been published with errors that have 
later been fixed. That's what the defect report process is about. 
Here we're dealing with two distinct sentences, each with different 
problems.  The first, as noted above, strikes me as completely 
inappropriate for a standard. The second is confusing. Presumably it 
can be clarified, and then we can debate whether it should be in the 
RFC.

>(5) You view the second sentence of the same quote (from RFC 2459) as

Yes, for exactly the reason I cited.

>criticise so severely. THIS WG wrote and reviewed the text...

You're right that I assumed you were the author, and I'll admit that 
my criticism was probably heightened by that thought :-).  However, 
if the criticism is valid, we should address it, irrespective of 
authorship.

Let's be accurate about this Peter.  WG's don't write text.  Authors 
write text.  In the case of any large document with many listed 
authors there are lots of opportunities for details to not be 
carefully reviewed.  We have uncovered a number of such details in 
2459.  I'm certain that several, perhaps most, of the long list of 
authors of 2459 have NOT reviewed MOST of the text for a long time. 
Tim is the one individual who, as the editor, has the best chance of 
keeping on top of the document.

>passed Final Call in both PKIX WG and IETF Final Call.

See comments above.

>not in PKIX WG, under the rules of our chairs.

The IETF last call is the means by which the IETF notifies interested 
parties that a document is about to become a standard, unless someone 
raises objections.  To the extent that consent by abstaining is 
consensus, then you're right, since that is what happens for most 
documents and most members of the IETF. Personally, I have used the 
last call to trigger reading of documents that I was not tracking, 
and I have made suggestions to the IESG re changes to such documents. 
Sometimes my proposed changes have been adopted, sometime not.  In at 
least two cases where I did not prevail, the matter was one of 
technical accuracy and my objections were overruled despite being 
objectively correct.  So, the process is far from perfect.

>a quoted passage represents an accepted practice to clearly identify the

I missed that, obviously.

So, where are we now?

Well, I stand by my objections to the text.  It is inappropriate to 
have inserted the first sentence into a standard, and I now propose 
to the WG that we remove it.

The second part also strikes me as very sloppy, for exactly the 
reasons I cited.  So, I propose removing it as well, unless someone 
can clarify the meaning, and then justify why it is present.

Presumably you don't argue that just because we published this text 
before that it is perfect.  To do so would suggest that we ought not 
be making all the other changes to 2459 that we have so far.  The 
only question now is whether the WG wants to retain this text, 
expressing such a desire via a positive action (vs. silent assent) or 
if the WG is willing to strike it.

Steve