Alexey Melnikov via Datatracker <nore...@ietf.org> wrote:
> Some comments below were still applicable to -27, but some might be out
of date.
> In 2.3.2:
(I've updated the text below from the -28 version, which does not use IRLs)
doc> A complete URI MAY be in this extension, including the 'scheme',
doc> 'authority', and 'path', The complete URI will typically be used in
doc> diagnostic or experimental situations. Typically, (and in
doc> consideration to constrained systems), this SHOULD be reduced to only
doc> the 'authority', in which case a scheme of "https://"; ([RFC7230]
doc> section 2.7.3) and 'path' of "/.well-known/est" is to be assumed, as
doc> explained in Section 5.
> This is not a problem per se, but mixing absolute URIs and iauthority in
the
> same field makes me rather uncomfortable. Maybe you can define ABNF for
this
> field to make it crystally clear what is allowed here. This would also
avoid
> the need to use SHOULD and MAY above.
The above reference to section 5 is vague, and I think it has gone lame, and
I've removed it. There is a single sentence in 5.0 that probably used to say
more.
The logic here (on the Registrar):
if(strchr(text, '/')) {
/* WHOLE URL is present */
url = text;
} else
snprintf(somebuffer, sizeof(somebuffer),
"https://%s/.well-known/est";, text);
url = somebuffer;
}
ruby:
def self.canonicalize_masa_url(url)
return nil unless url
if !url.blank? and !url.include?("/")
url = "https://"; + url + "/.well-known/est/"
end
# always have a trailing /
unless url[-1]=='/'
url = url + '/'
end
url
end
I'll have to think about how to explain this in ABNF. I would need to
reference the RFC7230 ABNF and create some hybrid item. It seems like a lot.
> In 2.3.2: "https" URI scheme needs a Normative reference.
I think that the new text deals with this already.
> 2.7. Cloud Registrar
doc> If the pledge uses a well known URI for contacting a cloud registrar
doc> an Implicit Trust Anchor database (see [RFC7030]) MUST be used to
doc> authenticate service as described in [RFC6125].
> Just referencing RFC 6125 is not clear enough, as there are lots of
parameters
> that need to be specified:
> a) which of CN-ID/DNS-ID/URI-ID/SRV-ID are allowed
> b) are wildcards allowed in any of these?
I've added text:n
The use of a DNS-ID for validation is
appropriate, and it may include wildcard compnents on the
left-mode side.
{i.e. what browsers and curl does. I feel that surely this must be specified
somewhere more precisely?}
--
Michael Richardson <mcr+i...@sandelman.ca>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ Anima mailing list Anima@ietf.org https://www.ietf.org/mailman/listinfo/anima
