Re: [Anima] Shepherd review draft-ietf-anima-bootstrapping-keyinfra-09

[Michael Richardson <[e-mail]>]

Sunday I was skiing (it didn't rain!) and this morning I was distracted by
another urgent matter, so I'll get another two hours to work on this now, and
then I'll post a new version of the draft before the deadline.

It is unlikely that I'll get through all your suggested edits, and I still
need to come back to William Atwood's comments and some followups to my
previous comments.  Sorry for so many emails: next time be more negligent :-)

Toerless Eckert <[e-mail]> wrote:
    > Section 2.4.3) 1)

    > a) Expand CMC.  "authenticate any pledge" -> "authenticate (the IDevID
    > of) any pledge"

expanded and linked to RFC5272.

    > 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.

What is the "(optional) EST server role"?
Nothing is optional in this document when operating for the ACP.
The EST server role is an EST server according 7030.

    > Here is my suggested text. If any explanation to cover this information
    > is felt to be too long for 2.4.3, please find another place but make
    > 2.4.3 refer to that place.

    > | A "Domain Join Registar and CMC" (abbreviated Domain Registrar in
    > most of the document) | serves two roles: BRSKI Bootstrap Service and
    > BRSKI enhanced EST Enrollment Service.

I don't think that there are two roles.

There is no requirement that the Join Registrar is also the EST for the
purposes of ongoing certificate renewal.  I don't know if you are speaking
about certificate lifetime management (renewal, etc.) when you say
"EST Enrollment service".  I'll assume that you mean that for the moment.

In a big network I would want the roles (bootstrap and initial certificate,
vs certificate renewal) split up.

So I don't think your text is correct; but if it is, then I don't want to
insert a bunch of text that is depth first into explaining everything when
the goal of section 2 is to go breadth first.
I opened an issue: https://github.com/anima-wg/anima-bootstrap/issues/46

    > | While not recommended, BRSKI Bootstrap Server and BRSKI enhanced
    > EST-Server can |be provided by separate servers. In this case, the
    > BRSKI Bootstrap Server must | support redirection of the Pledge after a
    > successfull requestauditlog to the | URI of a BRSKI enhanced
    > EST-Server.

no, that's not what I'm saying at all.
I would never want to redirect or reconnect after processing the voucher and
before issuing the first certificate to the pledge.  The entire "Secure
Transport" depends upon it occuring over a single TLS connection.

    > Section 2.4.4)

    > a) It would be IMHO good to move the (mayority of the) initial
    > paragraph of 5.4 into this section to explain what the scope of the
    > MASA functionality is by listing the interface services requestvoucher
    > and requestauditlog here - similar to how i proposed to summarize the
    > interfaces of the Domain Registrar above for section 2.4.3.

I have changed the text to say:

2.4.4.  Architectural component: Manufacturer Service

   The Manufacturer Service provides two logically seperate functions:
   the Manufacturer Authorized Signing Authority (MASA) described in
   Section 5.4 and Section 5.5, and an ownership tracking/auditing
   function described in Section 5.6 and Section 5.7.

    > 5.4 is not a good place to do that because it's only about
    > requestvoucher, and then after another non-maza intermezzo 5.6
    > requestauditlog is again about the MASA. So no single place summarizing
    > the MASA functionality at this level.

Section 5 is a time sequence explanation about the process.
We want from role based descriptions to time based descriptions based upon
feedback from implementers.
Section 5.6 is about pledge->JRC.

QUESTION: Max, I thought that the Voucher Status Telemetry was also to be
          relayed to the MASA?
          (I didn't implement that far yet)

    > -----------------------------------------------------------------------------

    > Section 2.4.x)

    > a) Please add subsection "Architectural Component: Key Infrastructure
    > (PKI)"

    > Suggested text (as in: this is the type of information i would like to
    > see explained here, whatever language you use):

    > | The Key Infrastructure (PKI) administers certificates for the domain
    > of concerns, | providing the trust anchor(s) for it and allowing
    > enrollment of Pledges | with domain certificates.

    > | The Domain Registrar ('s BRSKI Bootstrap service role) uses a Trust
    > Anchor (TE) | from the PKI in the BRSKI Voucher pinned-domain-cert to
    > authenticate itself to the | Pledge with the help of MASA.

I have put this text in place, but this paragraph is not quite correct.
I don't know how to fix it yet.

My text:

+2.4.5.  Architectural component: Public Key Infrastructure (PKI)
+
+   The Key Infrastructure (PKI) administers certificates for the domain
+   of concerns, providing the trust anchor(s) for it and allowing
+   enrollment of Pledges with domain certificates.
+
+   The Domain Registrar uses a Trust Anchor (TE) from the PKI in the
+   BRSKI Voucher pinned-domain-cert to authenticate itself to the Pledge
+   with the help of MASA.  (XXX fix me)
+
+   The Domain Registrar acts as an [RFC5272] Registration Authority,
+   requesting certificates for Pledges from the Key Infrastructure.
+
+   The above requirements and expectations against the Key
+   Infrastructure are unchanged from RFC7030.  This document does not
+   place any additional architectural requirements on the Public Key
+   Infrastructure.

    > b) Figure 1 labels the path to the PKI with "EST" and i remember Max to
    > repeatedly state that CAs could support EST. Nevertheless, i read in
    > RFC7030:

    > "The nature of communication between an EST server and a CA is not
    > described in this document".

So perhaps the labelling of the Domain Registrar/PKI interface shouldn't
say EST RFC 7030 afterall.

    > But then it defines the term "EST CA". So i am confused if there is an
    > actual spec stating the EST profile? of an EST CA.

You are asking for us to define what the northbound connection (well, in our
diagram, it's a southbound connection...) from the JRC to the PKI is.  What
we are trying to say is that it's not in scope, because it has no effect on
interoperation with the pledge or MASA.

The options include:
    1) CMC (RFC5272)
    2) CMP
    3) system("openssl xyz")  [it's all internal]
    4) a variety of RESTful interfaces,
        for instance https://www.digicert.com/rest-api/

I really don't think we should specify anything here because it will just be
ignored with vendors of JRCs doing whatever they need to do to get into the
customer.   On day one I expect to see (3) used a lot and others to follow.


    > -----------------------------------------------------------------------------

    > Section 2.5) 1)

    > a) If the following sentence is functionally correct, please add text
    > accordingly:

    >   Bootstrapping Pledges that have a Realtime Clock (RTC), SHOULD use it
    > to verify certificate validity.

    > b) And from my own experience, it should add:

    >   but they MUST be prepared to recognize local time failure and revert
    > to the above described mechanisms. For example when RTC battery failure
    > leads to a well-known default-time (e.g.: Jan 1 1970).

Done.


    > Section 2.5) 2)

    > a) Please move the bullet about the registrar behavior out of the
    > bullet list, maybe at the end of the section.  Even better: - rename
    > 2.5 to "Certificate Validity" - 2.5.1 "Lack of Realtime Clock in
    > Pledges - 2.5.2 "Infinite Lifetime of IDevID" (move text into 2.5.1)

okay.

    > b) Its hard to comprehend what the pargraph means to say. I think its
    > something like:

    >    According to RFC5280, IDevIDs are examples of certificates that
    > should have no well-defined expiration date. This is indicated through
    > the GeneralizedTime value of 99991231235959Z". Registrars SHOULD have a
    > configuration option to ignore IDevID lifetime values if they do not
    > conform to this recommendation.

Done.

    >    As expected, i always like an explicit example to bring it to the
    > point:

    >    For example, IDevID may have incorrect lifetime of N <= 3 years,
    > rendering replacement Pledges from storage useless after N years unless
    > registrars support this option.

Done.

    > -----------------------------------------------------------------------------
    > Section 2.6)

    > IMHO, without further text, it is unclear a) what a cloud registrar is,
    > b) why we care and c) how a solution using a cloud registrar would have
    > to be built to work.

I think that we explain why (b) well enough.
I prefer not to try to specify anything here for two reasons:

1) it's proprietary: No BRSKI is involved.
2) it's out of scope: No BRSKI is involved.
3) it's possible that it will be draft-ietf-netconf-zerotouch-20

So, I don't think your assumptions are right about who runs what.

{In my thinking about this, btw, the pledge calls home a la
netconf-zerotouch, and the vendor provided service acts as a Join Proxy to
the owners' JRC.  But, I'd want to write code and think about before
I dared document it.  Running code...}

    > If you feel this is overall too much, then maybe delete the whole
    > section 2.6 and put it into a followup document. Borderline to me. If
    > its "just" what i sugested above, its fine, if there is more to it to
    > make it work, maybe better in separate document.

No, we added this section because someone (maybe you) asked for it.

    > -----------------------------------------------------------------------------
    > Section 2.7 1)

    > a)

    >> Note that the Registrar can only select the configured MASA URL based
    >> on the trust anchor -- so vendors can only leverage this approach if
    >> they ensure a single MASA URL works for all Pledge's associated with
    >> each trust anchor.

    > I do not think this is true. A registrar could have configuration
    > policy mapping from IDevID serial-number patterns to MASA URI.

Yes, it could be more complex.
I'd rather delete that sentence than fix it.

    > Rewrite accordingly ? Let me know if you hate this approach, i had had
    > to brainstorm it for my planned yang model for ANI.

Only if this functionality is standardized :-)

    > b) I also think it might be necessary for Registrars to allow policies
    > that override MASA URIs learned from the IDevID because the longevity
    > of URIs can not always be guaranteed and the MASA may move (merger &
    > aquisitions etc.. ).

Agreed.

    > c) I am unclear from the document whether registrars may require
    > configuration to know what specific options for voucher-requests a MASA
    > supports.

> - If i understand it correctly, a registrar may use a voucher-request to
> request a voucher in the absence of the pledge (stage the voucher). This
> certainly is something not every MASA must support, so that would need to
> be configured.

The MASA must support nonce-less, unsigned voucher-requests.
You are right that we did not say that the MASA MUST do this.
I'm comfortable leaving that to some other applicability document.
  {e.g, "Use of BRSKI to bootstrap lightbulbs for underground military bunkers",
      MIL-SPEC 843.1958, by Strangelove, Sellers and George}

> - It is not clear to me if the Registrar can correctly fill out all
> Registrar voucher-requests in the presence of the pledge (aka: after
> receiving the Pledge voucher-request). See also discussion for Section
> 3. If this is not fully automatic, but may rquire Registrar configuration,
> this counfig should be mentionedhere.

Do you mean, in the absence of the pledge, or ...?

    > -----------------------------------------------------------------------------
    > Setion 3. 1)

    > So... I guess Registrars can request Vouchers for pledges before being
    > in contact with that pledge, right ?

    > If correct, the following would be less confusing to read for me:

Here is my revised text:

+   Voucher-requests are how vouchers are requested.  The semantics of
+   the vouchers are described below, in the YANG model.
+
+   A Pledge forms the "Pledge voucher-request" and submits it to the
+   Registrar.
+
+   The Registrar in turn forms the "Registrar voucher-request", and
+   submits it to the MASA server.
+
+   The "proximity-registrar-cert" leaf is used in the Pledge voucher-
+   requests.
+
+   The "prior-signed-voucher-request" leaf is be used in Registrar
+   voucher-requests to the Pledge voucher-request.  It contains the
+   encoded (signed form) of the Pledge voucher-request.
+
+   A Registar MAY also retrieve (nonceless) vouchers by sending voucher-
+   requests to the MASA.  No "prior-signed-voucher-request" leaf would
+   be included.  This can be used to retrieve vouchers for later offline
+   use.  The Registrar will need to know the serial number of the
+   pledge.  This document does not provide a mechanism for the Registrar
+   to learn that in an automated fashion.  Typically this will be done
+   via scanning of bar-code or QR-code on packaging, or via some sales
+   channel integration.


    > In any case, you need at least a forward reference for those leaf types
    > if you want to mention them without other explanations.

It's hard to reference into the YANG model text.

    > -----------------------------------------------------------------------------
    > Setion 3. 1)


    > a) Even with above concern Section 3. 1) fixed the section still does
    > not provide a good taxonomy of the different type of voucher-requests
    > and how to fully identify them because of the "may be used"...

I removed "may" to say "is".

    > b) There is no text here explaning how a registrar transforms a Pledge
    > Voucher request to a Registrar voucher request. If explained later,
    > insert a forward reference. Else. pls add text to explain.

I added some text above.

    > b) I have my doubts that the flow of the document is ideal with all the
    > yang formalisms thrown into section 3. If this is what other documents
    > do as well, fine. I for once would like it better if it was put into a
    > separate section towards the end of the document.

    > "nah, not going to happen" is an acceptable answer ;-)

"not going to happen"

    > -----------------------------------------------------------------------------
    > Setion 3.2 1)

    >  "provides voucher examples" -> "provides voucher-request examples"

okay.

Again, changes to here updated to: https://goo.gl/CpZHqd



--
Michael Richardson <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-