On Mon, Sep 13, 2010 at 08:12:47PM +0100, Dave Cridland wrote:
> On Mon Sep 13 18:59:03 2010, Stefan Santesson wrote:
> >I agree here. Both to this and to former speakers stating that the
> >assertion
> >is made by the CA and no the subject.
> >
> Well, I'd say the assertion is the presence of the SAN in the cert. I
> mean, an assertion is a positive statement made *without* evidence.
> The evidence is then the signature of the issuer, who certifies the
> assertion - it doesn't matter who makes that assertion. But anyway,
> that's somewhat moot, and as Shumon points out, we needn't care about
> who authorized what unto whom.
Yeah, that's what I meant. Thanks for articulating that more clearly
than I did Dave!
RFC 4985 specifies the SRVName othername form. The act of authorizing
a particular identity to be in a certificate is more related to who
issued and signed the certificate, and the act of verifying that
authorization is related to the client authenticating the signature
of the certificate and building a chain of trust from the issuer back
to a trust anchor that it has configured. 4985 doesn't need to say
any more on that subject since it's already covered by base PKIX specs.
> "The requested DNS domain name for the specified service. That is,
> the domain name which would be found in the URI for the service, and
> other protocol identifiers of a similar nature. Where the service is
> directly requested by hostname, this domain name would be the
> requested hostname."
>
> I think that covers all the cases I'd expect by example, without
> worrying about who's asserting and certifying. No doubt someone will
> reword with a sprinkling of 2119.
>
> Dave.
This particular sub thread is about errata to 4985, right? If so,
I don't think it should mention "URI" or "identifiers of a similar
nature". Or are you proposing more general text for inclusion in
draft-saintandre-tls-server-id-check?
For 4985, I think your first sentence is sufficient by itself.
"The requested DNS domain name for the specified service."
Or, if we want to elaborate more, I'd suggest:
"The requested DNS domain name for the specified service. This
is the "Name" component of the corresponding DNS SRV record."
Actually, what would be really useful is if the document provided an
actual example of an SRV record and and SRVName, right after the
definitions in Section 2. Lack of clear examples is a very common
problem with many IETF specifications.
--
Shumon Huque
University of Pennsylvania.
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf