Subject: Re: [certid] version -07

From: =JeffH <[email-masked]>
Date: Fri, 02 Jul 2010 22:46:30 -0700

As PaulH said ... finally decloaking after being off this topic for a while. 
Apologies for latency.

Peter, thanks for updating the draft!

All -- good discussion on the list, thanks for all the thoughtful contributions 
-- the spec is much better for it.

Yes, I have various bits of feedback on -07, some described below. this is 
without a careful review though, and is driven by reading through the recent 
threads on certid@ and checking -07 for how the issues were addressed. I concur 
with the decisions taken. It seems that all raised issues were nominally 
addressed in -07, so the below are (subtle-but-important) nits.

=JeffH
------

[ the below items aren't necessarily difficult to clean up, I'm just noting 
them for the record for now ]

* It seems to me coming to this new revision of the spec somewhat "fresh", that 
the concepts being addressed could build more cleanly from (especially) section 
1.1 (intro/motivation), section 2 Names, and section 3 Representation of Server 
Identity. I can take a whack at making concrete suggestions by early/mid this 
next week.

* need to explicitly define (at least) the below terms/phrases in section 1.3 
if we are going to use them..

    attribute-type-and-value pair

    DER encoding

    Internet application   ..or..   application service   ..or..   ?

    service provider

    subjectAltName   (this term is used in section 1.3 but isn't itself defined
                      until seciton 2.2)

* I think we need to review the terms/phrases we use to reference cert 
components and aspects thereof. I think we're being inconsistent and at times 
ambiguous (need to do careful review). unfortunately other specs we depend on 
use non-congruent terminology it seems.

E.g. in just sections 2.2 and 3 we use these various terms/phrases wrt 
"subjectAltName"...

   subjectAltName extension

   subjectAltName extension types

   subjectAltNames

   subjectAltName entry

   SubjectAltName field

   subjectAltName identifier

   subjectAltName identifier types

   subjectAltName identifier of type

   [the GeneralName structure in] the subjectAltName

..and then including the rest of the spec we also use (in addition to the above)..

   application-specific subjectAltName extensions

   subjectAltName extension of type

   subjectAltName extensions of type

Obviously various of the above terms/phrases are redundant and we ought to 
clean this up.

---
end

---

From: Kaspar Brand <[email-masked]>
Date: Sun, 04 Jul 2010 12:17:32 +0200

> Obviously various of the above terms/phrases are redundant and we ought to 

Agreed. My earlier suggestion ("subjectAltName entry") is mainly due to
the following statement in RFCs 2459/3280/5280:

   If the subjectAltName extension is present, the sequence MUST contain
   at least one entry.

"Extension" is actually the term for the whole container - i.e., I would
refrain from using wording like "subjectAltName extension of type X" (or
even "subjectAltName extensions", because a particular extension is only
allowed to occur once, as per RFCs 2459/3280/5280). Also,
"subjectAltNames" seems rather sloppy as a term, IMO.

Kaspar

---

From: Peter Saint-Andre <[email-masked]>
Date: Fri, 09 Jul 2010 13:40:32 -0600

> "subjectAltNames" seems rather sloppy as a term, IMO.

I've fixed these terminological confusions. We now use only two terms:

- subjectAltName extension (which can contain multiple entries)

- subjectAltName entry (a specific entry of type dNSName, SRVName, etc.)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 12 Jul 2010 08:52:06 -0600

On 7/2/10 11:46 PM, =JeffH wrote:
> As PaulH said ... finally decloaking after being off this topic for a
> while. Apologies for latency.
> 
> All -- good discussion on the list, thanks for all the thoughtful
> contributions -- the spec is much better for it.
> 
> Yes, I have various bits of feedback on -07, some described below. this
> is without a careful review though, and is driven by reading through the
> recent threads on certid@ and checking -07 for how the issues were
> addressed. I concur with the decisions taken. It seems that all raised
> issues were nominally addressed in -07, so the below are
> (subtle-but-important) nits.
> 
> =JeffH
> ------
> 
> [ the below items aren't necessarily difficult to clean up, I'm just
> noting them for the record for now ]
> 
> * It seems to me coming to this new revision of the spec somewhat
> "fresh", that the concepts being addressed could build more cleanly from
> (especially) section 1.1 (intro/motivation), section 2 Names, and
> section 3 Representation of Server Identity. I can take a whack at
> making concrete suggestions by early/mid this next week.

That sounds nice but not necessary. :)

> * need to explicitly define (at least) the below terms/phrases in
> section 1.3 if we are going to use them..
> 

Added to the terminology section (along with several other terms).

> components and aspects thereof. I think we're being inconsistent and at
> times ambiguous (need to do careful review). unfortunately other specs
> we depend on use non-congruent terminology it seems.
> 
> Obviously various of the above terms/phrases are redundant and we ought
> to clean this up.

Fixed, per my previous message.

> end

I hope we're nearing the end so that we can request a Last Call soon
(several specs now have dependencies on this I-D, including one that's
already been approved by the IESG and one that will soon go into IETF
Last Call).

Peter

-- 
Peter Saint-Andre
https://stpeter.im/