[Acme] 回复：Re: Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)

[皮皮猪 <[e-mail]>]

Hi  Mike, Michael, and all,

Thank you for the thorough discussion during the adoption call for draft-geng-acme-public-key-06, and especially for the concrete suggestions that helped us refine the draft into version -07. We greatly appreciate Michael Richardson’s detailed technical comments and Mike Ounsworth’s positive encouragement to continue the work.

We have posted version -07 (https://datatracker.ietf.org/doc/draft-geng-acme-public-key/07/) as a direct response to the concerns raised. 

Below we first summarise how -07 differs from -06, then respond to the specific points raised by Michael Richardson, and finally echo Mike Ounsworth’s call to keep the momentum going. We also welcome the offer to present the latest version at IETF 126.

1. What changed from -06 to -07 – direct responses to the adoption call

From -06 to -07, the key changes are: pk-01 is now a pure proof-of-possession (PoP) challenge, fully decoupled from identifier validation; server capability is advertised via popSupported inside the meta object; the popKeyAccepted field in the order provides deterministic server acceptance signalling and a clear CSR fallback path; a new popNotSupported error type indicates incompatible servers; the KEM PoP construction is fully specified (HKDF + HMAC with a fixed info string); reuse of the account key as the popKey is MUST be rejected; and the signature mode MUST use the mandatory domain separation prefix "ACME-pk-01-sig v1:". These changes directly address the working group’s adoption-call concerns around architectural separation, capability negotiation, backward compatibility, and security hardening.
2. Response to specific concerns raised by Michael Richardson
We agree with Michael Richardson that PoP should not be confused with identifier validation, and pk-01 now serves solely as a proof‑of‑possession challenge, attachable to existing identifier‑control authorizations. We also addressed his specific worries: the server MUST reject any popKey that equals the account public key (ensuring key separation), and the fallback logic is now unambiguous – if a client sends popKey and receives no popKeyAccepted field in the order object, it knows the server ignored the field and can safely fall back to the standard CSR‑based finalisation flow. These changes respond to Michael’s architectural and security concerns.

3. Thanks to Mike Ounsworth and a constructive way forward
We sincerely thank Mike Ounsworth for his constructive encouragement to continue discussing this draft on‑list and to propose a talk at IETF 126. Following his advice, we will submit a presentation proposal for the ACME session, where we can showcase how pk-01 works as a clean, pure PoP challenge, explain its KEM construction for post‑quantum keys, demonstrate the backward‑compatible fallback behaviour, and gather further implementation feedback. We believe this is the most productive way to move the work forward.

4. Current state and request

The draft is now at revision -07 and ready for another round of review. The most important changes are:


Clean separation of PoP from identifier validation.



Clear capability advertisement (popSupported inside meta).



Deterministic client–server agreement (popKeyAccepted).



Explicit fallback rules.



Full KEM PoP specification.



Prohibition of account‑key reuse.



Mandatory domain separation prefix.


We respectfully ask the WG to consider moving the document forward again, this time as a pure proof‑of‑possession extension.

Thank you again for the thoughtful reviews. We look forward to further discussion on the list and to presenting -07 at the upcoming meeting.

Best regards,

Geng Feng
(on behalf of the authors of draft-geng-acme-public-key)
         原始邮件
         
       
发件人：Mike Ounsworth <[e-mail]&gt;
发件时间：2026年5月27日 17:33
收件人：acme <[e-mail]&gt;
抄送：acme-chairs <[e-mail]&gt;, draft-geng-acme-public-key <[e-mail]&gt;
主题：[Acme] Re: Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)



Hi ACME,


The (extended) Call-for-Adoption ended yesterday. The extension did not generate any additional discussion with support for adopting or rejecting.


The outcome of the CfA is:



No WG consensus to adopt.

Good technical discussion, with some suggestions for ways forward; the authors are being very responsive to feedback with new versions of the draft.

We encourage this draft to continue to be discussed on-list and we encourage the authors to submit a talk to ACME 126.

If the interest in this draft increases, then we can do another CfA in the future.



On Thu, 21 May 2026 at 11:10, 皮皮猪 <[e-mail]&gt; wrote:

Hi ACME,

Thank you all for the discussions so far. We note that the Call for Adoption has been extended to 2026-05-26, and the thread seems to have slowed down.

We plan to submit draft-geng-acme-public-key-07&nbsp;(attached) immediately after CFA.&nbsp;

We appreciate Michael's objection. It encouraged the authors to promptly finished the exploration of DCV-PoP, with consensus, completely decouple PoP from DCV. In version -07, we adopted Ilari's encapsulation-then-MAC approach for KEM key PoP in his April 24 email, following the suggestion from Tim Hollebeek in his April 29 email. Meanwhile, the authors have considerable reviewing and incorporating the valuable&nbsp;discussion and revision suggestions contributed by John Gray, Ilari Liusvaara, David Benjamin, Aaron Gable and Richard Barnes at IETF 125. Thank you all.




We also submitted draft-geng-acme-idp-00&nbsp;(available on Datatracker: https://datatracker.ietf.org/doc/draft-geng-acme-idp/).&nbsp;

Based on the consensus at IETF 125, the authors would split pk-01 and opaque-01 (at that time) from draft-geng-acme-public-key-04 into two separate draft. The result draft idp-01, which is where the authors' core interest lies, see my April 2 email.



Abstract  &nbsp; This document defines an Identity Control Validation (ICV) framework  &nbsp; for the ACME protocol [RFC8555], introducing a new ACME identifier  &nbsp; type "idp" and a new challenge type "idp-01".&nbsp; The ICV framework  &nbsp; allows ACME servers to delegate trusted Identity Providers (IdPs) to  &nbsp; verify certificate applicants’ control over the claimed identities.  &nbsp; This document also defines an optional X.509 certificate extension,  &nbsp; the Trust-Domain-Restricted Certificate Extension, which explicitly  &nbsp; indicates that certificates issued via the ICV framework are backed  &nbsp; by a specific IdP trust domain and whose trustworthiness depends on  &nbsp; the current status and policies of that IdP, preventing trust leakage  &nbsp; into contexts outside the IdP’s trust domain.  &nbsp; This extension is parallel to Domain Control Validation (DCV)  &nbsp; [RFC8555]; either can independently verify an applicant’s control  &nbsp; over identities/resources and request certificates.  &nbsp; Proof-of-Possession (PoP) [I-D.geng-acme-public-key] serves as an  &nbsp; auxiliary enhancement framework.&nbsp; Based on this architecture, two  &nbsp; standardized certificate enrollment models are formed: the Domain  &nbsp; Validation model (DCV + optional PoP) and the Identity Validation  &nbsp; model (ICV + optional PoP).&nbsp; This document focuses on the latter.  &nbsp; This document defines three deployment models: the IdP-Operated  &nbsp; Certificate Model, the Intra-PKI Domain Mutual-Trust Model, and the  &nbsp; CA-Integrated IdP Model.&nbsp; It supports multiple authentication  &nbsp; protocols via the extensible idp_method parameter, covering both  &nbsp; device and account identities.



We hope these two drafts together&nbsp;help illustrate the full picture of what pk-01 with ICV and DCV enables.

We welcome any further review, feedback, or even strong objections on pk-01. We'd like to hear more voices – both supportive and critical – to help the chairs gauge consensus and decide whether to move forward. If you have concerns, please articulate them. If you support adoption or see value in having a decoupled PoP mechanism in ACME, please chime in.

We appreciate Michael Richardson again! We do like your objection feedback!&nbsp; We welcome more objection again!&nbsp; Something is better than nothing! &nbsp;:-) . . .

Thanks Mike. You are friendly, proactive and professional .




Best regards,

Feng, on behalf of the authors




原始邮件


发件人：Mike Ounsworth <[e-mail]&gt;
发件时间：2026年5月13日 10:40
收件人：皮皮猪 <507069=[e-mail]&gt;
抄送：Michael Richardson <[e-mail]&gt;, [e-mail] <[e-mail]&gt;, [e-mail] <[e-mail]&gt;, draft-geng-acme-public-key <[e-mail]&gt;
主题：[Acme] Re: Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)



Hello ACME,


I notice that in this whole thread only one person actually answered the adoption questions (which was Michael Richardson&nbsp;who said "I would not adopt."). I remind you that the adoptions questions were:

 1) Does the WG want to work on a new ACME challenge for public key  proof-of-possession towards goals such as removing the CSR, enrolling  KEM certificates, and potentially other applications?
 
 2) Does the WG feel that this draft is a reasonable starting point for discussing and designing a solution to (1)?




There is not enough in this thread for me to make a consensus call, so I am going to extend the Call For Adoption by another two weeks.




[chair hat off]


As a WG participant, I believe:


1) yes, extending ACME to allow alternate PoP mechanisms is a valuable thing for the WG to spend effort on.


2) yes, I believe this draft provides a good starting point that we can iterate. In particular, the authors seem happy to take design feedback from the WG, so I believe that if we start from this draft, we will arrive at a solution that everyone is happy with.



On Tue, 5 May 2026 at 18:47, 皮皮猪 <507069=[e-mail]&gt; wrote:

Hi Michael,

To clarify the architectural reasoning behind the pk-01 proposal, I would like to outline how we see the verification dimensions in ACME.

ACME [RFC8555] models certificate enrollment as an order containing a set of identifiers. Each identifier maps to an authorization that carries a set of challenges. Existing challenges such as dns-01 and http-01 address Domain Control Validation (DCV).

Early versions of the pk-01 draft (prior to -05) also explored Identity Control Validation (ICV) for non-DCV scenarios. This line of exploration originated from the sso-01 draft and several subsequent related drafts.At that stage, public-key identity binding and Proof-of-Possession (PoP) were interleaved, aiming to shift the paradigm from "controlling communication resources" toward "controlling the claimed identity."

Following extensive discussion, beginning around draft -05/-06, community feedback converged on the view that PoP should be fully decoupled as an independent component. The central question, therefore, is not whether to replace the CSR, but rather: what mechanism should prove possession of a public key, and how can that mechanism be combined orthogonally with both the existing DCV framework in ACME and any future ICV?

In short, the ACME protocol suite comprises three independent verification dimensions, each supported by its own protocol framework. DCV and ICV stand as parallel capabilities; either can independently satisfy identifier validation and support certificate issuance. PoP is an independent verification dimension. It may be used together with DCV or ICV and may also serve alone as the basis for certificate requests when an order contains only the "pk" identifier.

In my understanding, the three are fully orthogonal to each other.
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; ACME identifier
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;+------------+------------+
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;| &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;dns-01 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;pk-01 &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;idp-01
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; v &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;v
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp;DCV &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;PoP &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ICV
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp;&nbsp;&nbsp; (fully decoupled) &nbsp;&nbsp;&nbsp; &nbsp; &nbsp; &nbsp;|
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; +------------+------------+
&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; | &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; |
&nbsp;DCV + (PoP) &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;ICV + (PoP)


DCV&nbsp;[RFC8555]: Do you control this domain name?
ICV (idp-01): Do you control this identity?
PoP (pk-01): Do you possess this private key?


Best regards&nbsp;
Geng Feng &nbsp; &nbsp; &nbsp; &nbsp;&nbsp;
原始邮件


发件人：Michael Richardson <[e-mail]&gt;
发件时间：2026年5月5日 23:16
抄送：[e-mail] <[e-mail]&gt;, [e-mail] <[e-mail]&gt;, [e-mail] <[e-mail]&gt;
主题：Re: [Acme] Call for adoption: draft-geng-acme-public-key-06 (Ends 2026-05-12)




palos.chen&nbsp;<[e-mail]&gt;&nbsp;wrote:
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;It&nbsp;seems&nbsp;that&nbsp;this&nbsp;almost&nbsp;suffers&nbsp;from&nbsp;the&nbsp;same&nbsp;mis-understanding&nbsp;of
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;challenges&nbsp;as&nbsp;acme-rats&nbsp;originally&nbsp;did.&nbsp;At&nbsp;least&nbsp;though,&nbsp;the&nbsp;intention
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;is&nbsp;that&nbsp;it&nbsp;is&nbsp;pk-01&nbsp;OR&nbsp;dns-01&nbsp;OR&nbsp;http-01&nbsp;OR&nbsp;...&nbsp;(not&nbsp;AND&nbsp;as&nbsp;rats
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;needed)

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;In&nbsp;-07,&nbsp;pk-01&nbsp;is&nbsp;no&nbsp;longer&nbsp;entangled&nbsp;with&nbsp;identifier&nbsp;validation.&nbsp;We
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;introduced&nbsp;a&nbsp;new&nbsp;"pk"&nbsp;identifier&nbsp;type&nbsp;(Section&nbsp;3);&nbsp;pk-01&nbsp;is&nbsp;bound&nbsp;to
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;"pk"&nbsp;identifiers&nbsp;and&nbsp;proves&nbsp;possession&nbsp;of&nbsp;the&nbsp;certificate&nbsp;private&nbsp;key
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;only.&nbsp;Existing&nbsp;challenges&nbsp;(dns-01,&nbsp;http-01,&nbsp;...)&nbsp;remain&nbsp;bound&nbsp;to&nbsp;their
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;own&nbsp;identifier&nbsp;types&nbsp;per&nbsp;[RFC8555]&nbsp;without&nbsp;modification.

But,&nbsp;it's&nbsp;the&nbsp;wrong&nbsp;approach.
You&nbsp;have&nbsp;to&nbsp;change&nbsp;pk-01&nbsp;each&nbsp;time&nbsp;someone&nbsp;comes&nbsp;along&nbsp;with&nbsp;a&nbsp;new&nbsp;challenge
type.&nbsp;&nbsp;&nbsp;What&nbsp;you&nbsp;are&nbsp;doing&nbsp;is&nbsp;orthogonal&nbsp;to&nbsp;the&nbsp;challenge.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;The&nbsp;async/sync&nbsp;modes&nbsp;of&nbsp;-06&nbsp;are&nbsp;entirely&nbsp;removed&nbsp;in&nbsp;-07.&nbsp;pk-01&nbsp;no
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;longer&nbsp;carries&nbsp;any&nbsp;identifier&nbsp;control&nbsp;role.&nbsp;Existing&nbsp;extensions
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;(onion-csr-01,&nbsp;subdomain,&nbsp;dns-persist,&nbsp;etc.)&nbsp;continue&nbsp;to&nbsp;operate
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;unchanged&nbsp;alongside&nbsp;pk-01.

okay,&nbsp;but&nbsp;I&nbsp;still&nbsp;think&nbsp;this&nbsp;is&nbsp;the&nbsp;wrong&nbsp;direction.
I&nbsp;think&nbsp;that&nbsp;what&nbsp;you&nbsp;are&nbsp;proposing&nbsp;is&nbsp;useful,&nbsp;but&nbsp;it's&nbsp;a&nbsp;fundamental&nbsp;change
to&nbsp;ACME,&nbsp;and&nbsp;should&nbsp;be&nbsp;treated&nbsp;that&nbsp;way.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;Replacing&nbsp;the&nbsp;CSR&nbsp;with&nbsp;something&nbsp;better,&nbsp;something&nbsp;that&nbsp;can&nbsp;deal&nbsp;with
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;keys&nbsp;that&nbsp;can't&nbsp;make&nbsp;signatures&nbsp;(either&nbsp;do&nbsp;to&nbsp;math&nbsp;or&nbsp;policy)&nbsp;is
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;important.&nbsp;I&nbsp;had&nbsp;proposed&nbsp;work&nbsp;like&nbsp;this&nbsp;if/when&nbsp;we&nbsp;start&nbsp;RFC7030bis.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;We&nbsp;share&nbsp;this&nbsp;motivation.&nbsp;KEM-key&nbsp;support&nbsp;is&nbsp;in&nbsp;fact&nbsp;one&nbsp;of&nbsp;the
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;primary&nbsp;reasons&nbsp;for&nbsp;a&nbsp;dedicated&nbsp;PoP&nbsp;mechanism&nbsp;rather&nbsp;than&nbsp;relying&nbsp;on
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;the&nbsp;CSR&nbsp;self-signature,&nbsp;which&nbsp;is&nbsp;impossible&nbsp;for&nbsp;KEM-only&nbsp;keys.&nbsp;-07
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;supports&nbsp;ML-KEM-512/768/1024&nbsp;via&nbsp;a&nbsp;Decapsulate&nbsp;+&nbsp;HKDF&nbsp;+&nbsp;HMAC&nbsp;PoP&nbsp;—&nbsp;see
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;Section&nbsp;5.2&nbsp;(KEM&nbsp;PoP&nbsp;construction)&nbsp;and&nbsp;Section&nbsp;5.4&nbsp;(KEM&nbsp;algorithm
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;registry).

Then,&nbsp;let's&nbsp;fix/replace&nbsp;CSR.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;The&nbsp;ACME&nbsp;server&nbsp;should&nbsp;simply&nbsp;announce&nbsp;the&nbsp;set&nbsp;of&nbsp;POP&nbsp;methods&nbsp;that&nbsp;it
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;can&nbsp;support,&nbsp;with&nbsp;CSR&nbsp;being&nbsp;the&nbsp;default.&nbsp;I&nbsp;don't&nbsp;think&nbsp;a&nbsp;new&nbsp;challenge
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&gt;&nbsp;method&nbsp;is&nbsp;the&nbsp;correct&nbsp;way&nbsp;to&nbsp;negotiate&nbsp;this.

&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;This&nbsp;is&nbsp;the&nbsp;one&nbsp;architectural&nbsp;point&nbsp;where&nbsp;we've&nbsp;taken&nbsp;a&nbsp;different
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;direction,&nbsp;following&nbsp;the&nbsp;chair's&nbsp;earlier&nbsp;guidance&nbsp;and&nbsp;the&nbsp;model&nbsp;that
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;ACME&nbsp;has&nbsp;consistently&nbsp;used:&nbsp;challenges&nbsp;bound&nbsp;to&nbsp;identifier&nbsp;types
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;(dns-01&nbsp;for&nbsp;dns,&nbsp;http-01&nbsp;for&nbsp;dns-via-http,&nbsp;onion-csr-01&nbsp;for&nbsp;onion,
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;etc.).&nbsp;-07&nbsp;introduces&nbsp;a&nbsp;"pk"&nbsp;identifier&nbsp;type&nbsp;and&nbsp;a&nbsp;pk-01&nbsp;challenge
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;bound&nbsp;to&nbsp;it,&nbsp;which&nbsp;keeps&nbsp;the&nbsp;architecture&nbsp;modular&nbsp;and&nbsp;aligned&nbsp;with&nbsp;how
&nbsp;&nbsp;&nbsp;&nbsp;&gt;&nbsp;the&nbsp;working&nbsp;group&nbsp;has&nbsp;handled&nbsp;similar&nbsp;extensions.

I&nbsp;think&nbsp;the&nbsp;chairs&nbsp;are&nbsp;wrong&nbsp;here&nbsp;:-)

I&nbsp;don't&nbsp;think&nbsp;this&nbsp;is&nbsp;a&nbsp;good&nbsp;direction&nbsp;to&nbsp;go,&nbsp;because&nbsp;I&nbsp;don't&nbsp;think&nbsp;your
needs&nbsp;are&nbsp;not&nbsp;the&nbsp;same&nbsp;as,&nbsp;for&nbsp;instance,&nbsp;.onion.


--
Michael&nbsp;Richardson&nbsp;<[e-mail]&gt;&nbsp;&nbsp;&nbsp;.&nbsp;o&nbsp;O&nbsp;(&nbsp;IPv6&nbsp;IøT&nbsp;consulting&nbsp;)
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;Sandelman&nbsp;Software&nbsp;Works&nbsp;Inc,&nbsp;Ottawa&nbsp;and&nbsp;Worldwide

**&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;My&nbsp;working&nbsp;hours&nbsp;and&nbsp;your&nbsp;working&nbsp;hours&nbsp;may&nbsp;be&nbsp;different.&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;**
**&nbsp;Please&nbsp;do&nbsp;not&nbsp;feel&nbsp;obligated&nbsp;to&nbsp;reply&nbsp;outside&nbsp;your&nbsp;normal&nbsp;working&nbsp;hours&nbsp;**





 

_______________________________________________
 Acme mailing list -- [e-mail]
 To unsubscribe send an email to [e-mail]