rcontent.com/anima-wg/anima-bootstrap/master/dtbootstrap-anima-keyinfra.txt
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/ | rub
vs CBOR-in-COSE.
4) future ID: JWS-signed-JSON vs JSON-in-JOSE.
I note that for some of these "signed" is redundant.
We do not have COSE-signed-JSON, or JWS-signed-CBOR.
Which feels more natural to you?
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman
permission-less resale of devices, as well as guarding against
business failure of the BRSKI [I-D.ietf-anima-bootstrapping-keyinfra]
Manufacturer Authorized Signing Authority (MASA).
In addition, there is some interest in a JWS-signed-JSON draft.
--
Michael Richardson. o O ( IPv6 IøT consulting
on't quite know why it is saying this yet.
We have quite a number of issues in the air, and I have some emails
half-written based upon the design team discussion which I have not yet
completed.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works I
ned-JSON voucher format from
industry.
{I thought to have a draft ready, but that won't happen in the next 35 minutes}
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signat
I wrote draft-richardson-anima-registrar-considerations
was so to capture some of my thinking about how different networks can/should
operate their BRSKI Registrar.
If the WG wants to discuss different ways of operating/building a registrar,
perhaps the WG would like to take another look at the above d
operations.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
t-ietf-anima-bootstrap-keyinfra
Amount of time requested: 6 minutes
Presenter name(s): Michael Richardson
Name of time slot: BRSKI-cloud use case/applicability
Name of draft(s): draft-friel-anima-brski-cloud-03
Amount of time requested: 6 minutes
Presenter name(s): Michael Richardson, Owen Friel
Name
s document is being worked on in the ANIMA-WG, and on github at:
> https://github.com/anima-wg/enrollment-roadmap
> Please note that it may take a couple of minutes from the time of
submission
> until the htmlized version and diff are available at tools.ietf.org.
> The IETF
Michael Richardson wrote:
> I am working on a pull request for brski-ae now.
Only, it's not in github that I can find.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signat
On 2020-09-29 11:36 a.m., Michael Richardson wrote:
On *THIS* Thursday, I happen to have a conflict until 8am.
But, next week, no problem at 7:30am.
(Come to my webinar on Software Updates...
iotsecurityfoundation.org/consumer-iot ...)
Hi, there was a meeting last week from 8:10am to just
On 2020-10-01 6:36 p.m., Benjamin Kaduk via Datatracker wrote:
A couple of the new bits in the -29 might benefit from targeted review (noted
inline), e.g., for CDDL, TSV, or INT-specific aspects.
Carsten has already done that for CDDL.
I'm unclear what TSV and INT specific things you have in
Warren sent an email to the RFC-editor informing them that the LC on the
name change was success, but it wasn't CC to the list.
https://www.rfc-editor.org/cluster_info.php?cid=C325 shows version
-44 in queue.
My understanding is that the ACP document has been revised according to
the Erik
Michael Richardson wrote:
> Technology (in my order of preference):
> 1) https://meet.sandelman.ca/I control it completely. JITSI.
> 2) https://whereby.com/anima a service I pay for.
> 3) ietf.webex.comI can set up a mee
uestion, did you already plan the appointment or invite
> for the meeting based on the doodle?
> https://doodle.com/poll/7hvge372s8gz9kzn
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Descript
n the
RFC-editor queue.
Then constrained-voucher ate up constrained-BRSKI, and now it is bigger.
I would say, that the WG should adopt the work based upon what things it
wants to solve, and then if content needs to be shifted around, merged,
split, etc. then the WG can decide that.
--
Michael Ric
r guidance on where they we go.
This document could be merged into ietf-constrained-voucher, but I think we
made it a separate document because it is not needed on all networks, just
*constrained* multihop/MESH networks.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelma
Just CC'ing the WG on Mark's feedback. He is the .well-known expert reviewer.
His comments are implemented in -44.
Mark Nottingham wrote:
>> On 22 Sep 2020, at 2:15 am, Michael Richardson
wrote:
>>
>>
>> Mark Nottingham wrote:
>>> I n
doodle poll at:
https://mailarchive.ietf.org/arch/msg/anima/HVTfaf9FcwfA0j4U4NqLMYsiQYU/
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ie
sing, officially.
> Could you please reopen issue #144 ? ( It looks like I can't do that.)
> Not all the issues we're discussing are currently addressed by the
> Github commit.
I've done that.
--
Michael Richardson. o O ( IPv6 IøT consulting )
San
registry to be separate from it.
Cheers,
> On 17 Sep 2020, at 1:08 am, Michael Richardson wrote:
>
>
> Warren Kumari wrote:
>> having to assume EST. Therefore the above BRSKI diff (and BRSKI-AE) propose
>> to introduce a /.well-known/brski registry.
>
> I be
ake something less efficient than the unconstrained protocol and
> force clients to use it ... ?
I also agree.
In my opinion the only reason to do this discovery is to enable multicast RD,
such as I think that brski-ae really wants to do.
--
Michael Richardson. o O ( IPv6 IøT consulting
d to author these updates? (Or does this need to be
> taken up in the errata once we publish as RFC...? I remember that
> people want to rather have it published than polished.)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature
rm the CA, which would mean it is a
> message further forwarded by the registrar. This also means that
> additional information for the registrar, e.g., about enrollment
> attempts may not be contained in these messages.
The enrollment_status message could be extended to include
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[
signature.asc
Description: PGP signature
_
e, in which case, I'd say that they are probably broken in more profound
ways. I have not encountered a framework where it matters.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works| network architect [
rfc/rfc6690.html#section-4.1 ]
does not seem to permit two or three things to be returned, just wildcards.
What would happen if, when asked for rt=anima.brski, that it returned the
entries for ace.est and/or blah.cmp?
Is it late enough that we could just switch to CoRAL?
Do I even understand what means.
ne for EST will translate well.
I do not feel strongly either way, but in the diff I left a ?XXX because I
didn't know.
I am sorry to bring this up during the IETF last-call: I think that I just
need some confirmation from CMP experts that we aren't creating something
that is unimplementable.
--
Michael
will mostly go by sharing
screen with github pull requests enhancing the document(s).
When answering this, please assume that that the meeting will occur weekly on
the time proposed.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
.
--
Michael Richardson. o O ( IPv6 IøT consulting )
Sandelman Software Works Inc, Ottawa and Worldwide
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
in at AUTH48, or can give them to
the RFC-editor beforehand, is probably unimportant.
If this WG are okay with my proposed text, I'll ask Sean Turner+LAMPS to review
it, and tell me what was imprecise.
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Ric
Fries, Steffen wrote:
>> -Original Message-
>> From: Michael Richardson
>> Sent: Freitag, 28. August 2020 20:32
>> > Maybe I phrased it wrong. The intention is not to make the pledge more
>> > complex. The goal should be t
"and [RFC5280] section A.1's list of standard attributes"
https://github.com/anima-wg/anima-bootstrap/commit/c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99
commit c7a7eb46e78d761c5cb0f50a9dfa95f820d74b99
Author: Michael Richardson
Date: Tue Sep 1 21:25:05 2020 -0400
fix section 2.3.1 to
e error!
here is the complete change:
https://github.com/anima-wg/anima-bootstrap/commit/41dbb30bfd163b71818144a122291a83b50a85e0
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
; {
description "A last-renewal-date field
is not valid in a voucher request, and
any occurrence MUST be ignored";
}
This is, I think, an editorial change.
--
Michael Richardson , Sandelman Software Works
-= IPv6
thought that the furnace in the basement where there is no
connectivity was a really good use case.
The furnace installer has a smartphone or dedicated comissioning device.
As for HTTP: I would tend to suggest that we should use CoAP.
This works over WIFI as well as other t
tside in terms of the protocol. The intention
> was to only specify the necessary (signature wrapped) data objects to
I'd really like to have the PUSH part in scope.
I thought that it was just not done yet, but it seems to me that without the
PUSH part, that the protocol isn't async at al
> https://tools.ietf.org/html/draft-ietf-anima-constrained-voucher-08
> With the result of two more characters "/est/" --> "brski", maybe the
> draft-ietf-anima-constrained-voucher should shrink this part to
> something like "/br/", "/
e interfaces
would stop being suppressed. This falls into the quality of implementation
category at this point.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@
but that's a cosmetic issue.
it appeals to humans, but it makes no technical difference.
Nevertheless, if we can do this quickly, then let's do it.
I've provided proposed text in the form of a diff, the ADs have agreed to a
process, the chairs , just need to run it.
I hope that your(Siemens) Thomas Werner
about that renaming.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
can tolerate the process risk, then it shouldn't be a problem.
If we can agree by the end of the week to do this, then the changes could be
approved in less than a week, if the ADs agree that this does not require a
new IETF LC.
--
Michael Richardson , Sandelman Softwa
Thank you for the comments.
Mark Nottingham wrote:
>> On 4 Aug 2020, at 10:07 pm, Michael Richardson
wrote:
>>
>>
>> Hi Mark, this concerns some desired changes to /.well-known/est.
>>
>> Specifically, to move the things we did
Elliptic Curve Private Key
> - Repository: anima-wg/anima-bootstrap
This is an interesting development where github tries to keep us from
uploading our private keys... in this case, the keys used for examples!
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
-anima-keyinfra.txt
but the DT/cache refuses to believe -42 exists yet, but maybe in 30 minutes
it will be okay.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing
her a rename, or don't do it.
4) If we want to do this, then do it in the base document.
Yes, with *ALL* the delay risk that Brian Carpenter mention.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: P
ail that it appears to be work that
the IEEE should do. He may be right. In which case, this may be a
requirements document to send through a liason.
On the other hand, this is basically an IPv6-over-FOO document, and we have
historically done those.
At this point, please take section 4 (Possibilities)
of supporting BRSKI-AE CoAP over BTLE,
NFC, and SMS. (not necessarily with an IP layer)
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https
: 7 min
Presenter name(s): Michael Richardson
Please note that there is a conflict with secdispatch, so I need to be after
the first 30min.
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
Name of time slot: brski-cloud
Name of draft(s): draft-friel-anima-brski-cloud-02
Time requested: 10min
Presenter name(s): Michael Richardson
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
when we realized that a new
document obsoleted some of the recommendations. It took longer than planned,
but that was partly because the other document had to settle a bit.
I think we could do this in the time for the 2nd WGLC and about four days.
--
Michael Richardson , Sandelman Software Works
. This email does not include my opinion, as it has not yet
been formed.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org
>> of the IKEv2 daemon that we need to use :-(
> No, you are not forced to use anything. Your ID could be KEY_ID with
No, the ACP document has been forced to use otherName in it's
certificates. That's nothing to do with IPsec/IKEv2.
But, that that's what IKEv2 will have to deal wi
ect alt name or subject name to
> identity or information in the policy.
So, we've been forced to use otherName, and this will cause new code in some
of the IKEv2 daemon that we need to use :-(
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
De
e for ULA space fd00::/10 in order to
prevent loops. This shouldn't be a big deal.
The RPL DODOG root will in mature situations be the ACP registrar,
and while the market is less mature, in an router designated as the
ACP-connect.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT cons
o read
the C
>> code underneath to learn how that worked.
>> (false, is I think, whether it is critical)
The table is at: openssl/crypto/asn1/asn1_gen.c. If it's in a document
somewhere, I never found it.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting
Name:1.3.6.1.4.1.46930.1;UTF8:%s",
self.sanitized_eui64),
false))
The hardest part was figuring out the ";UTF8:" part, as I had to read the C
code underneath to learn how that worked.
(false, is I think, whether
y for
interest in the
> early allocation, so pls. chime in with a +1, or if you must a -1 and
explanation.
> I'll do a +1 from the authors side.
> The remaining requirements of RFC7120 for early allocations are AFAIK met.
--
Michael Richardson , Sandelman Software Works
t this point.
> Yepp. I think to remember that MaxP was thinking of suggesting to
> talk about dealing with expired certs for our cases in i think LAMPS too
> but longer ago...
yes, the document wound up in ACME, and I think they did a good job, although
it is proscriptive for ACME
Toerless Eckert wrote:
>> After providing place holder values for IANA1 and IANA2, I compiled
>> the ASN.1 module. It compiles without errors!
Is it worth asking for early allocation?
I'd like to write code now, and I hate putting my PEN into the code to make
it work.
Proxy.
Perhaps this needs to be in a new document at this point.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman
The IANA section is a bit of a clearer pointer, but I sure wish we'd point
people straight at the the place we mean by URL.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima ma
in first, but it is already implemented.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
a string.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
ASN1 code generators).
I would prefer CBOR encoding, if there is consensus that it should not be a
string.
This also anticipates more modern certificate-like artifacts (CoID).
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP
On 2020-06-23 10:31 p.m., internet-dra...@ietf.org wrote:
> A diff from the previous version is available at:
>
https://www.ietf.org/rfcdiff?url2=draft-ietf-anima-autonomic-control-plane-25
yes, I read the diffs :-)
- This document describes a modular design for a self-forming, self-
-
o with the MUST-/SHOULD+/SHOULD- terminology
from
IPsecME's RFC8247.
It would be nice if SAAG lifted section 1.1 into a BCP14-like document, as I
think that it has widespread applicability throughout documents that want to
establish interoperable crypto.
--
Michael Richardson , Sandelm
authority", then perhaps
the tide of the terminology will be reversed.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
hat.
Why do you think Netscape did that?
What should they have done instead?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
with CMP objects, then it may be easier to integrated into
existing CMP infrastructure.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https
dblock in the way of deploying the ACP.
And, now have an ACME method past WGLC that does certificate validation by
SMTP.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailin
he eventual home owner, who could rekey into 1-6.
see https://datatracker.ietf.org/doc/draft-fries-anima-brski-async-enroll/
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
__
actually voted rather
than Abstained or No Comment, then we'd have actual rough consensus, and the
IESG seems to have abandonned that.
Benjamin Kaduk wrote:
> On Tue, Jun 16, 2020 at 02:14:24PM +1200, Brian E Carpenter wrote:
>> On 16-Jun-20 12:20, Michael Richardson wrote:
>
to get into CAs than otherName is?
Seriously, how does that help at all?
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
Anima mailing list
Anima@ietf.org
https://www.ietf.org/mailman/listinfo/anima
to avoid, so that won't be popular.
And of course, there could also be bugs (maybe even CVEs) in the code that
tries to deal with the tie.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
int, I think
that it is not of general interest and it is better kept isolated.
<%> leveraging Clarke's third law, but possibly also 1st and 2nd law as well.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: P
to be built-into the firmware.
internet-dra...@ietf.org wrote:
> A new version of I-D, draft-richardson-anima-masa-considerations-04.txt
> has been successfully submitted by Michael Richardson and posted to the
> IETF repository.
> URL:
>
https://www.ietf.org/intern
Michael Richardson wrote:
>> In the Security Considerations I encounter MTIM which I suspect should
>> be MITM (and which needs expanding on first use in s.5).
oops, I missed committing this one.
___
Anima mailing list
Anima@ie
the reference file should have that , but I think the
XML->TXT throws that out, but the XML is authoritative now...
Brian E Carpenter wrote:
> Again thanks to Michael Richardson, here are some important nits in the
> GRASP examples in the BRSKI draft. The CDDL syntax i
I read the ietf-anima-grasp-api document awhile ago.
I validated that the non-threaded version made sense.
The document is ready to be published.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
nated here.
This document might not fit into ANIMA, or the IETF at all.
(Oh, I know that we've published such documents before, but I'm not claiming
that was necessarily a good thing)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelma
the ACP really wants to see both chassis
seperately. So it occurs to me that we could hack LACP rather than LLDP :-)
It appears that it uses a specific multicast destination.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
119') # LL
multicast
> GRASP_LISTEN_PORT = 7017 # IANA port number
Thank you.
Is there any reason why the source port (for DULL, and normal) can't be port
7017 as well?
It clearly could be any port...
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signat
Michael Richardson wrote:
rob> [As an individual] Would it be possible to carry some static
rob> information in LLDP that could be used to setup the autonomic control
rob> plane outside of LLDP? This would presumably require bridges to have
rob> some minimal support
Michael Richardson wrote:
> His opinion is that this would be a serious misuse of the LLDP protocol
> and cause problems for implementations. The general expectation and
> design of LLDP is that the information contained in the PDUs is fairly
> static in nat
The issue of not
rob> forwarding IPv6 packets for an interface in L2 mode could potentially
rob> be mitigated by targeting the IPv6 packets to the peer interface MAC
rob> address, or possibly use the "Nearest Bridge group multicast MAC
rob> address" (i.e. 0
Michael Richardson wrote:
> Brian, I was looking for the multicast destination for GRASP DULL
messages.
> Section 6 tells me that IANA has not yet assigned it.
> I'm surprised we didn't ask for an Early Allocation.
> Is it worth asking now?
I found it in the
er tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[
signature.asc
Description: PGP
to do the right packet forwarding for the hybrid case seems
an
> invitation to trouble.
I'm not happy about any of the L2 text; I would have left it out completely.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
sign
ME spec does support authorizations for domains, and maybe that
would be the best way to do this.
This also supports the concept that the cmcRA bit ought to apply to all RA
operations (CMP and well as EST), as proposed in LAMPS.
I think that we should perhaps plan a design team meeting/BOF a
be (2) then all is fine.
> A few remaining nits found during reading:
Thanks. I have updated my copy of the XML, and I'll pass this on to the
RFC-editor.
Nothing is going forward until the ACP LC ends and the IESG does it's reviews.
--
Michael Richardson , Sandelman Software Works
-= IP
Toerless, thank you for a beautifully complete agenda document.
(I have seen some doozies this week...)
--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works|IoT architect [
] m...@sandelman.ca http
Toerless Eckert wrote:
> Operational Considerations for BRSKI Registrar
> draft-richardson-anima-registrar-considerations-03
You should have had it uploaded 20 minutes ago.
___
Anima mailing list
Anima@ietf.org
p/notes-ietf-interim-2020-anima-01
{It was, until a few hours ago, a redirect to port 9009, but it is not
anymore. Same content, same server, but the port 443 has less capacity due to
search engines, etc, trying to index it}
--
Michael Richardson , Sandelman Software Works
-= IPv6 Io
the document is ready for IESG evaluation but I, as the
> shepherding AD, consider that the amount of changes requires a new IETF
> Last Call.
I have read the latest document, and I am happy with the result.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
Thank you Ben for the edits suggestions.
I have implemented many of your minor edits in the XML.
I will answer some of your questions later this week.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
there be a problem.
> 2) This sentence seems inappropriate in this section. This section and
> the upper-level section is talking about the device's IDevID. Suddenly
> mentioning the MASA key doesn't make sense.
I understand.
I guess what I'm trying to do is co
uot;device" and not pledge!
We did not insist on cmcRA be set in section 5.1, specifically because we
didn't know if RA:TRUE was something we could insist upon here.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
___
t burning "trees". It's the sequence/etc. that
probably matters. If the asn1parse output is totally meaningless, I would
not be opposed to removing it.
The goal of these examples is to provide input to other implementations.
I have generated -40 and I am posting it now.
--
Michael Richa
te certificates signed by this same root CA.
I believe that by number of Registrar's the self-signed private CA will be
the most common. It is what I have suggested in
draft-richardson-anima-registrar-operations.
--
Michael Richardson , Sandelman Software Works
-= IPv6 IoT consulting =-
signature.
501 - 600 of 1078 matches
Mail list logo
