Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Brian Smith
Eliot Lear wrote: > On 21 Apr 2021, at 20:25, Brian Smith wrote: > > otherName [0] OtherName, > rfc822Name [1] IA5String, > dNSName [2] IA5String, > x400Address [3]

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Eliot Lear
> On 21 Apr 2021, at 20:25, Brian Smith wrote: > > Eliot Lear mailto:l...@cisco.com>> wrote: > If this is scoped to dnsNames then I’m fine with it going forward as is. > Other names would be problematic. > > Could you be more specific as to what other names would be problematic and > list t

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Brian Smith
Eliot Lear wrote: > If this is scoped to dnsNames then I’m fine with it going forward as is. > Other names would be problematic. > Could you be more specific as to what other names would be problematic and list them explicitly? Here are the choices in a GeneralName: otherName

Re: [Uta] Some draft-ietf-uta-use-san nits

2021-04-21 Thread Salz, Rich
Victor suggests replacing section 3.3 as follows: OLD: When constructing a list of reference identifiers, the client MUST NOT include any CN-ID present in the certificate. ... NEW: When constructing a list of presented DNS identifiers, the client MU

[Uta] Some draft-ietf-uta-use-san nits

2021-04-21 Thread Viktor Dukhovni
On Wed, Apr 21, 2021 at 01:06:21PM -0400, Viktor Dukhovni wrote: > On Wed, Apr 21, 2021 at 06:50:56PM +0200, Eliot Lear wrote: > > > If this is scoped to dnsNames then I’m fine with it going forward as > > is. Other names would be problematic. > > It was my expectation/understanding all along t

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Tony Finch
Viktor Dukhovni wrote: > On Wed, Apr 21, 2021 at 06:50:56PM +0200, Eliot Lear wrote: > > > If this is scoped to dnsNames then I’m fine with it going forward as > > is. Other names would be problematic. > > It was my expectation/understanding all along that we're talking about > is deprecation of

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Viktor Dukhovni
On Wed, Apr 21, 2021 at 06:50:56PM +0200, Eliot Lear wrote: > If this is scoped to dnsNames then I’m fine with it going forward as > is. Other names would be problematic. It was my expectation/understanding all along that we're talking about is deprecation of CN-ID fallback when the reference id

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Hubert Kario
On Wednesday, 21 April 2021 18:50:56 CEST, Eliot Lear wrote: Brian, If this is scoped to dnsNames then I’m fine with it going forward as is. Other names would be problematic. why? iPAddress is actually used in SANs -- Regards, Hubert Kario Senior Quality Engineer, QE BaseOS Security team Web

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Eliot Lear
Brian, If this is scoped to dnsNames then I’m fine with it going forward as is. Other names would be problematic. Eliot signature.asc Description: Message signed with OpenPGP ___ Uta mailing list Uta@ietf.org https://www.ietf.org/mailman/listinfo/ut

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Brian Smith
Eliot Lear wrote: > [+iotops] > > Brian, > > On 21 Apr 2021, at 00:22, Brian Smith wrote: > > Eliot Lear wrote: > >> The issue for me is library support. If libraries take the doc too >> seriously, it screws the apps that really need to do the right thing for >> their use cases. >> >> > What y

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Eliot Lear
One correction: > What harm comes to any use case for there to be a non-default library flag, > as Victor mentioned there is with OpenSSL? The flag is there. I don’t know the default state. Eliot signature.asc Description: Message signed with OpenPGP

Re: [Uta] How should we change draft-ietf-use-san?

2021-04-21 Thread Eliot Lear
[+iotops] Brian, > On 21 Apr 2021, at 00:22, Brian Smith wrote: > > Eliot Lear > wrote: >> The issue for me is library support. If libraries take the doc too >> seriously, it screws the apps that really need to do the right thing for >> their use cases. >