I would ideally like to begin the WGLC once I've posted the revised document and then take any of your issues that I wasn't able to resolve as last call comments (open issues on tools or github).
Toerless Eckert <t...@cs.fau.de> wrote:
> d)
> I am missing in the initial chapters a succinct summary how EST
> enrollment is optional and what can be achieved with/without it, there
> is only some side sentences later in the EST sections. I would suggest
> to insert such an explanation here.
> After point 4 insert (unnumbered) paragraph:
I have added a paragraph at the end of section 4:
After step 4, the pledge has received and authenticated an
explicit TA (trust anchor) (pinned-domain-cert in the Voucher
response). A secure transport exists between pledge and registrar,
and it may be used for things other than enrollment into a PKI.
> Also maybe insert some dotted line between imprint and enroll in Figure
> 2 to highlight this distinction. Maybe with "mandatory" / "optional"
> (EST enroll part) on the right hand side
But, in the ACP case, which we are documenting, it's not optional, so
I prefer to show the ACP case in all diagrams.
> Section 2.3)
> a)
> The first paragraph is too terse and not very explanatory arguing why
okay, I'ave used your text.
> - (Optional) authorizing pledge (by registrar) to receive certificate
> from local CA.
Are you referring to the signed CSR?
That's signed by the private key, and does not directly involve the public
certificate part. The "Signing of voucher-request" actually also is about
the private key too....
So I'm taking your comments, but maybe here we need to open an issue?
see: https://goo.gl/viMcAG
and: https://goo.gl/SNzWtJ
> Please keep the "There is no requirement for a common root PKI
> hierarchy. Each device vendor can generate their own root
> certificate."
Done.
>
-----------------------------------------------------------------------------
> Section 2.3 2)
> a) Please put the description of identification of the pledge into a
> subsection 2.3.1 "Identification of the Pledge"
done.
> b) I am confused about the first MUST (serialNumber) and following
> SHOULD (HardwareModuleName).
> The conversion rules make it clear that you want the device to be
> uniquely identified via the serialNumber, but if that is not in the
> certificate, then you would use the HardwareModuleName. Therefore the
> conversion rules contradict the MUST for serialNumber. Or else you
> wouldn't define a fallback if it does not exist.
We really want it in the serialNumber.
We acknowledge the PKI tools suck, particularly the ones without source code,
and it's likely that some variety of creation tools will be unable to comply
or the Registrar / Certificate Authority will be unable to do the right thing.
The 30 year history of trying make PKIX thing work properly has provided
experience that says that as much as we want to write MUSTs, if we don't have
workaround documented, then things will fail. It's sad.
> c) The MUST/SHOULD bullet points are IMHO a duplication of the
> conversion rules, so maybe just drop them.
I think an issue is warranteed here.
> d) I would start the section with a sentence clearly describing what is
> done here:
> In the context of BRSKI, pledges are uniquely identified by a
> "serial-number". This serial-number is used both in the "serial-number"
> field of Voucher or Voucher requests (see section 3.) and in local
> policies on Registrar or MASA (see section 5.).
> The serial-number is derived from the IDevID as follows:
> ... then add the three bullet-points.
okay, I think that I got this.
> e) I do not see "serialNumber" attribute mentioned in rfc4514 nor
> rfc4108. You mention "previously defined". Could you provide a
> reference where "serialNumber" was defined ?
https://github.com/anima-wg/anima-bootstrap/issues/44
so, it's rfc4514 "string representation" format, of the RFC5280 SerialNumber
https://tools.ietf.org/html/rfc5280#section-4.1.2.2
RFC4108 has hwSerialNum, but that's point two.
I'm not sure how to clarify this well.
> f) Please provide example of each of the three fields and how they
> convert into serial-number. This is especially important because for
> the average reader who has never seen a certificate (and with no actual
> reference to e.g.: serialNumber format thats easily readable), it may
> be hard to understand if or how something called "serialNumber" can
> unique identify a device - aka: that it includes also the device-type
> (unless a company only produces one type of device and somehow even the
> name of the company can be implied).
I created issue 45.
https://github.com/anima-wg/anima-bootstrap/issues/45
>
-----------------------------------------------------------------------------
> Section 2.3 2)
> a) Please put the description of MASA URI into a subsection 2.3.2 "MASA
> URI"
done.
> b) If the following statements are correct, i would suggest to
> integrate them into the section text to make it clearer and more
> explicit. If not then i did not understand how it is meant to work and
> the explanations could be approved accordingly to make it clearer:
> - The type and format of the MASA URI indicates the protocol supported
> by the MASA.
> - If a MASA supports multiple protocols, multiple
> instances of the new MASA URI can be put into the certificate.
I don't think so.
If there was a protocol that wasn't BRSKI-MASA, then it would have a new
extension defined.
QUESTION/DISCUSS.
> - This
> document defines the BRSKI-MASA protocol. It is indicated through a URI
> of the form
> MASA URI is "https:// authority "./well-known/est".
> see section 5 for more explanations. (this would replace the current
> sentence mentioning section 5).
> c) We discussed the risk of introducing new certificate fields and
> potential compatibility issues with existing code parsing such a
> certificate. Which is why we went for the obfuscated email encoding of
> the ACP information in the LDevID. It would therefore be good to have
> an explaining sentence why the new MASA URI extension is a better
> solution than encoding into existing attributes and safe to deploy into
> devices.
Well, I'm not convinced we needed to do that in the ACP.
On the other hand, the open source IPsec (IKE) implementations I'm familiar with
have relatively simple DER implementations, and are easily extended.
I am aware of IPsec implementations which are total disasters in this way,
and they would no more be able to parse the obfuscated email than an extension.
> I am not sure about the full extent of the answer, but probably IDevIDs
> are meant to and actually used in a far smaller and newer set of
> software than that processing arbitrary LDevIDs. Therefore the risk is
> smaller and the clean encoding outweights the risk of compatibility
> issues with badly written old software.
The manufacturer creates the certificates, the pledge never has to examine
it. The registrar has to examine it, and the registrar has to be new code.
Where we get into trouble, I think, is with the PKI interfaces.
>
-----------------------------------------------------------------------------
> Section 2.4.1) 1)
> "it does has network" -> "it does have network"
> But better: "it does only require subnet (link) local connectivity to
> the circuit proxy but no routeable IPv6/IPv6 address (exception: see
> section 2.6)".
Already changed, but added your text.
>
-----------------------------------------------------------------------------
> Section 2.4.2) 1)
> "The proxy mechanism" -> "The circuit proxy mechanism"
> " optional stateless mechanism" -> "optional stateless proxy
> mechanism"
> add: The registrar (likely?) also needs manual configuration of
> per-MASA credentials to contact them (see section 5.3).
okay.
> Q: Any case where unauthenticated BRSKI-MASA connections make sense ?
QUESTION: This seems like a non-sequitor to me.
>
-----------------------------------------------------------------------------
> Section 2.4.3) 1)
It's 2.4.4, I think. About the Manufacturer Service.
> Suggest to clarify roles: separate functions: the MANDATORY ...MASA
> including audit log, and an ADDITIONAL OPTIONAL Ownership Tracker
> providing sales channel integration.
I don't think it's optional.
> Aka: reuse same terminology so readers are not confused. Maybe go
> through text to check only "ownership tracker" and "sales channel
> integration" are used for that part.
>
-----------------------------------------------------------------------------
> Section 2.4.3) 1)
> a) Expand CMC. "authenticate any pledge" -> "authenticate (the IDevID
> of) any pledge"
> b) The document is still very vague on terminology to distinguish
> between the initial bootstrap and the (optional) EST server
> role. Please come up with a clear terminology and clearly summarize the
> functionality required to be supported by the roles.
I think that this no longer reflectes the text?
That's today's edits are at the same rfcdiff URL, since the file is
loaded by reference:
https://goo.gl/CpZHqd
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] m...@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
--
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
