[cabfpub] SRV Ballot

[Ryan Sleevi]

On Fri, Jun 10, 2016 at 12:02 PM, Erwann Abalea <Erwann.Abalea at docusign.com>
wrote:

> Since this ballot adds another name type, it has an impact on the
> definition of a technically constrained CA (section 7.1.5), not reflected
> here.
> At a minimum, add an item (d) in section 7.1.5:
>
> (d) For each otherName of type SRVName in permittedSubtrees, , the CA MUST
> confirm that the Applicant has registered the Name or has been authorized
> by the domain registrant to act on the registrant’s behalf in line with the
> verification practices of section 3.2.2.4.
>
>
> and change the phrase
>
> If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended
> key usage, then the Subordinate CA Certificate MUST include the
> Name Constraints X.509v3 extension with constraints on dNSName,
> iPAddress and DirectoryName as follows:‐
>
> to
>
> If the Subordinate CA Certificate includes the id‐kp‐serverAuth extended
> key usage, then the Subordinate CA Certificate MUST include the
> Name Constraints X.509v3 extension with constraints on dNSName,
> iPAddress, DirectoryName, and otherName of type SRVName as follows:‐
>
>
Erwann, the rationale for this decision was covered the previous time this
ballot was discussed.

See my reply https://cabforum.org/pipermail/public/2016-April/007211.html ,
Peter's follow-up, and mine, and see if that provides sufficient context.


> Should we also add specific requirements when such a CA is not allowed to
> issue certificates with an otherName of type SRVName, as it was defined for
> iPAddress and dNSName (setting these types in the excludedSubtrees portion
> of NC)?
>
> Reading RFC4985, it’s impossible to have an empty SRVName (the ASN.1
> definition forbids it). The logic described in section 4 doesn’t consider
> the case where both Name and Service are absent. We could specify that a CA
> not allowed to issue otherName:SRVName certificates must have a single
> « . » in this entry, but I’m not sure the logic described in section 4 is
> ok with this.
>

I'm not sure the answers here, but thanks for bringing them  up, as I
hadn't considered fully the implications for this aspect.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20160610/6ee08718/attachment-0003.html>