Re: [certid] version -07

[Peter Saint-Andre <[e-mail]>]

On 7/4/10 4:17 AM, Kaspar Brand wrote:
> On 03.07.2010 07:46, =JeffH wrote:
>> * 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.
> 
> 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.

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/